Vendors / Mainstream commercial restaurant POS
Lightspeed Restaurant
Lightspeed Restaurant (Lightspeed Commerce Inc., NYSE/TSX: LSPD)
dossier live
- Claims in scope
- 278
- Scored
- 278
- Assessed
- 278
- Unknown
- 0
- Not applicable
- 36
- Values challenged
- 93
Identity
- Owner
- Lightspeed Commerce Inc.
- Founded
- Lightspeed Commerce founded 2005 in Montreal, Canada. Lightspeed Restaurant is the hospitality line; the current flagship is 'K-Series' (iKentoo lineage - Lightspeed's own K-Series help centre tells merchants to "choose iKentoo (now Lightspeed K-Series)"), with O-Series, L-Series and G-Series still referenced on the developer portal. O-Series is the Kounta line and is still documented as a live product for AU/NZ merchants on o-series-support.lightspeedhq.com (Kounta appears in 236 of its 281 articles and in none of K-Series' 537).
- Scale
- Approximately 150,000 total Customer Locations and $22.9 billion total GTV in the quarter ended 2026-03-31 (FY2026 Q4 release, 2026-05-21). These are consolidated across Retail, Hospitality and Golf; within the stated growth engines (NA retail + EU hospitality) Lightspeed reports approximately 97,000 Customer Locations, up 11% year over year. No Restaurant-only location count, ARR or market-share figure is broken out in the release - restaurant-specific scale remains unknown.
- Who it is for
- Independents and small chains, roughly 1-20 locations, strongest in full-service, bars, cafes and hotel F&B. The published tiering ($69 / $189 / $399 per month plus an Enterprise quote tier) points at single-site to small-group operators; genuine enterprise and franchise capability is quote-only and thinly documented. The centre of gravity has moved decisively to Europe - Lightspeed's stated core growth engines as of FY2026 are 'retail in North America and hospitality in Europe', and on 2026-04-29 it divested the Upserve U.S. hospitality product line to Skyview Equity, transferring roughly 3,200 U.S. hospitality customer locations. K-Series is still sold in USD in the U.S., but a U.S. restaurant buyer should read the strategy as reduced U.S. hospitality investment.
- Site
- https://www.lightspeedhq.com/pos/restaurant/
Lineage
- 2005 — founded: Lightspeed founded in Montreal by Dax Dasilva, initially as a Mac-native retail POS.
- 2019-03 — ipo: Lightspeed POS Inc. lists on the Toronto Stock Exchange; a New York Stock Exchange dual listing follows in September 2020 under LSPD.
- 2019-11-01 — acquired: Acquired Kounta Holdings Pty Ltd, an Australian cloud hospitality POS serving SMB restaurants, cafes, bars and nightclubs in Australia and New Zealand. Kounta became Lightspeed Restaurant O-Series (its help centre still titles articles 'Kounta Insights', 'Stocktaking with Kounta'); K-Series descends from iKentoo, not Kounta. Terms undisclosed.
- 2020-01-07 — acquired: Announced the acquisition of Gastrofix, a German cloud hospitality POS with over 8,000 customer locations, for approximately US$61 million cash plus 1,437,930 subordinate voting shares at US$28.16, with contingent deferred consideration. Established the Central European hospitality footprint (Germany, Austria, Norway).
- 2020-12 — acquired: Acquired Upserve Inc. of Rhode Island, adding approximately 7,000 U.S. restaurant customer locations and over $6 billion of trailing-twelve-month GTV, plus the analytics technology that became Lightspeed Insights.
- 2026-04-29 — divested: Divested the Upserve U.S. hospitality product line to Skyview Equity for up to US$81 million (US$37 million contingent on earnout), transferring approximately 3,200 U.S. hospitality customer locations and about 70 employees, and roughly $140 million of FY2026 revenue and $5 billion of GTV. Lightspeed retained the Insights analytics technology and restated its core growth engines as retail in North America and hospitality in Europe.
Pricing
transparency: partial · unit: mixed · processor lock-in: partial
- Software
- Published US monthly tiers on the vendor pricing page (retrieved 2026-08-02): Starter $69/month; Essential $189/month; Premium $399/month; Enterprise = custom quote. Kitchen Display System is $30/screen/month on every tier - the only hardware-adjacent price Lightspeed publishes. Lightspeed Reservations, Reservations integrations and Lightspeed Tasks are asterisked add-ons at the entry tier. Two tier attributions were re-read directly off the page on 2026-08-02 and are decision-critical. 'Raw API access' and 'Multiple revenue center support for hotels' sit under Premium ALONE - absent from both Starter and Essential - so API access costs a $330/month subscription delta from entry, or $210/month from Essential, per location. Advanced inventory management by contrast appears on Essential and Premium but is annotated 'Also available on all plans as an add-on', so it is purchasable at Starter rather than tier-locked. Enterprise is the only tier advertising 'unlimited launch and consultation services'. Page disclaimer: 'Prices may vary depending on the nature of the business and the industry.' Additional register licences are commonly reported at $59/month, but that figure appears only in third-party roundups and is not admissible - unknown.
- Card processing
- Not published. The Lightspeed Payments page publishes no rate at all: it markets 'simple pricing', 'no hidden fees or markups' and 'the rate is always the same no matter what card your customer chooses to pay with', then routes merchants to sales for a volume-based quote. The only published fee disclosures are a $15 chargeback fee and deposits 'within 2 business days'. The widely circulated 2.6% + $0.10 card-present figure is third-party reporting only and is not used as evidence here.
- Contract
- Not published on the pricing page. The public Lightspeed Service Agreement states the agreement automatically renews for a duration equal to the Initial Term unless either party gives written notice at least 90 days before the end of the Current Term (or a period equal to the Current Term if shorter than 90 days; 30 days minimum where there is no Order Form). The Initial Term length itself is quote-specific and unknown.
- Early termination
- An ETF exists and is in the vendor's own published Service Agreement - early customer termination incurs non-recurring fees owed, all remaining recurring fees for the term, and the difference between list price and any discounted pricing received, with 'all payments by Customer to Lightspeed under this Agreement are non-refundable'. Lightspeed publishes no dollar figure and no pro-ration.
- Hardware
- Only the KDS SKU carries a published price ($30/screen/month); terminals, stands, printers and cash drawers are quote-only and no vendor price list was located, so hardware cost is unknown - third-party price bands exist but are not admissible. Separate the price question from the compatibility question: a named-model compatibility matrix IS published in the K-Series 'Supported hardware' article (iPads 7th gen+, iPhone 11-15, iPadOS/iOS 18+; receipt printers from SNBC, Blue Bamboo, Epson, Seiko, Bixolon and Star Micronics over LAN/USB/Wi-Fi/Bluetooth; Zebra ZD410 labels; Socket Mobile scanners; Safescan, APG and Lightspeed VPOS cash drawers; Verifone P400+/V400m/e285/e280, Mobile Tap, AMS1 and S1F2 terminals; Apple TV-based Order Display Screen). Lightspeed 'only provides support for the hardware listed in this article' but acknowledges third-party purchase of matching models. No scales and no bump bars appear anywhere in the list.
API posture
public API: partner-gated
- Cost to integrate
- Two gates, one of them priced. The developer portal states 'Access to the Lightspeed Restaurant K-Series APIs is reserved for Lightspeed partners and approved merchants', and the restaurant pricing page lists 'Raw API access' under the Premium tier alone - so the merchant-side cost is a $330/month subscription delta from Starter, or $210/month from Essential, per location, before any partner-approval step. There are three documented routes to credentials and none is self-service: approved partners register for the Developer Portal, merchants 'can request access by contacting their Account Managers', and other developers 'can apply to become partners'. No separate partner fee, revenue share or per-location API charge is published.
- Webhooks
- Documented but unhardened. K-Series webhooks span staff/shift events (shift.created, shift.updated, shift.deleted), reservations, order and payment events, and PMS transaction detail. Endpoints are CRUD-managed via API with Bearer auth. No HMAC signature verification, no retry/backoff policy and no replayable event log are documented.
- Data export on exit
- Adverse. Back Office supports CSV exports of reports and stock, and the financial and orders APIs give programmatic access, so a live customer can get data out. But the Service Agreement provides that on termination 'Lightspeed may immediately deactivate Customer's account and delete Customer Content' - there is no post-termination grace window, and no full-history export bundle is documented. The same agreement does confirm the customer retains ownership of Customer Content.
- Notes
- Reference documentation is genuinely public and reasonably rich - orders/checks/payments, menus and modifiers, item CRUD with pictures and allergen data, employees/shifts/permissions, tax rates, payment methods, daily financials, reservations, PMS. Auth is OAuth2 authorization-code only, with space-delimited scopes (financial-api, orders-api, offline_access); access tokens live 25 minutes, refresh tokens 30 minutes or 40 days with offline_access. Separate demo (auth.lsk-demo.app) and production (auth.lsk-prod.app) environments exist, but API clients bind to one server and demo accounts are created by approved partners, so there is no open sandbox. No numeric rate limits are published for K-Series (legacy Kounta published 60/min basic and 180/min OAuth; Retail X-Series publishes a 5-minute-window limit - neither governs K-Series). Read the posture precisely: the docs are public, the API is not.
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
Graphical editor is real: tables are scaled by 'pulling and pushing the table edge', a Table type field offers round or square, Number of covers sets capacity, and multiple floor plans represent 'each area in your restaurant'. Shortfall: the claim's fourth element, assigning sections to servers, is not documented. Neither this article nor Managing users and floor plans links a floor plan or section to a POS user; that article covers permissions via user groups only. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804656709-Creating-and-managing-floor-plans-and-tables · 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
'If an order was taken in table service mode with items assigned to particular seats, the check can be split according to those seats,' and 'Split the checks by tapping Distribute by seat. Once done, each item is automatically put onto a separate check for its corresponding seat.' Seat tagging at entry plus automatic post-hoc split with no re-keying - both halves of the claim documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360051089493-Check-splitting · retrieved 2026-08-02 adversarially verified
Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.
order-capture-coursing-hold-fire
Coursing documented in Table Service mode. An explicit hold-and-fire-next-course action from a handheld is not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050328374-About-ordering · retrieved 2026-08-01
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
Split by seat and by covers (even shares) documented. Arbitrary-amount splits and merging checks/tables after partial payment are not. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360051089493-Check-splitting · retrieved 2026-08-01
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
Pre-authorization is real: 'Pre-authorization guarantees payment of the pre-authorized amount, not necessarily the order total,' with a default hold amount set in Back Office. Shortfall: the two other halves of the claim are undocumented — no mechanism to incrementally re-authorize as the tab grows (a tab exceeding its hold only turns the card status yellow), and no end-of-day auto-close of stale tabs. Further gated to 'accounts using Lightspeed Payments located in Australia, UK, and the US.' https://k-series-support.lightspeedhq.com/hc/en-us/articles/4408089985179-Creating-and-managing-bar-tabs · retrieved 2026-08-02 adversarially verified
An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.
order-capture-transfer-audit
Transfers between tables and users are documented, gated by permission: POS configurations offer 'Restrict table transferring to managers only: When enabled, only POS users with manager permissions can transfer customers between tables', and 'You can control who can transfer items to another table from the Back Office though your POS user permissions.' The Transactions report (4403189403675) records transfer events as types 'Foreign: An order was transferred from one table to another' and 'Transfer'. Shortfall: the report entry is not documented as naming both employees. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804606610-Managing-and-understanding-POS-configurations · retrieved 2026-09-03 adversarially verified
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
Vendor documentation, not just a store listing: Tap to Pay on iPhone lets the K-Series app 'accept Apple Pay, contactless credit and debit cards, and other digital wallets through a quick tap on an iPhone' with no additional hardware. The App Store listing (Lightspeed Commerce Inc., iOS 18.5+/iPadOS 18.5+) states orders are 'sent directly to the kitchen or the bar'. Native app on the handheld itself, not a mirrored session. https://k-series-support.lightspeedhq.com/hc/en-us/articles/10071706424347-Tap-to-Pay-on-iPhone-with-Lightspeed-Payments · 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
The vendor does publish an offline assurance, under 'Handling an outage': 'If your network or internet service goes out, most basic order-taking functions will still work offline. But you'll still want to get back online quickly to use your hardware and process card payments.' That is offline order entry stated by the vendor, and it is why this is no longer unknown. Shortfall: 'most basic order-taking functions' is never enumerated, so what does and does not work offline is NOT published — modifiers, kitchen send and cash tender are nowhere confirmed, and the same sentence puts hardware and card payments outside the offline envelope. The counter-evidence stands: the 'Networking for Lightspeed Restaurant' guide requires outbound connectivity to *.lightspeed.app, *.ikentoo.com and *.adyen.com and 20 Mbps per POS device, describing no offline mode; peer-to-peer LAN ports are supplementary. Same source and same reading as reliability-local-transaction-engine, which is partial on this article for the same shortfall. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53288894613787-Troubleshooting-network-issues · retrieved 2026-08-11 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
CLAIM: guest QR at-table ordering writes items onto the same open check as server-entered items, not a separate ticket. SERIES: K-Series (iKentoo) - Order Anywhere table profiles and features.lsk.lightspeed.app are K-Series (lsk) surfaces; nothing here concerns O-Series (Kounta). NEW SURFACE: features.lsk.lightspeed.app, the vendor's production K-Series 'Product Updates' WordPress site (found via crt.sh on lightspeed.app; robots User-agent * Disallow: empty), read in full through /wp-json/wp/v2/posts (X-WP-Total 134) + pages (1). VERDICT: partial. EVIDENCE: the 2022-06-23 post 'Order Anywhere: Introducing Scan and Pay!' (live 200 on 2026-09-17): 'Orders added via Order Anywhere or from a waiter are synchronized immediately so guests are able to see all orders easily via the app (without any need of refresh). Once a partial payment is made, the order total is automatically updated. Guests can easily view the activity log informing them of what was added to their table order and what was paid.' That is a vendor statement that QR-guest items and waiter-entered items sit together on one table order the guest can split and pay. SHORTFALL (why not yes): (1) the source is a product announcement with promotional copy (grade C), 4 years old; (2) the current K-Series help centre (546-article corpus) never says a table-profile Order Anywhere order is appended to a server-opened check - 'Fulfilling orders from Order Anywhere' says only 'Table orders : Sync to the POS immediately after they are placed', and 'Enabling payments for Order Anywhere' says Scan and Pay lets customers 'pay for Order Anywhere orders by scanning the QR code attached to their specific table'; (3) the production API reference shows a table CAN hold several separate orders: GET /o/op/1/order/table/{tableNumber}/getCheck 'Returns an open order for a specific table. Note: If more than one order is assigned to the table, the oldest order will be returned.' (https://api-docs.lsk.lightspeed.app/operation/operation-apegetcheck), and Create Local Order 'If the accountIdentifier of an existing order is provided in the body of the request, the request will update the existing order' - so appending to an open check is an API capability for integrators, but whether first-party QR orders merge or open a second account is not stated at grade B. Retrieved 2026-09-17. https://features.lsk.lightspeed.app/order-anywhere-introducing-scan-and-pay/ · 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
CLAIM: a first-party self-order kiosk rendering the same menu and modifier tree as the POS with no separate menu build, AND vendor-documented ADA/accessibility conformance for it. WHAT IS MET, AND IN WHICH SERIES: the kiosk conjunct is met and it is O-SERIES ONLY. Lightspeed publishes a full O-Series setup guide for a first-party product: 'With Lightspeed Kiosk, customers can place their own orders, cutting down on lines at the counter' and 'The Lightspeed Kiosk O-Series app is compatible with our supported iPad devices, and all payments are processed through Lightspeed Payments' (https://o-series-support.lightspeedhq.com/hc/en-us/articles/45638355445275-Setting-up-Lightspeed-Kiosk). It runs the existing catalogue, not a second build: 'The kiosk displays all products enabled for visibility in the Online products section. To configure customer-facing names and visibility settings, navigate to Back Office > Products > Online products'; the modifier tree carries over - '(Optional) If the product comes with variants or option sets, select your desired variant and options'; and availability is inherited - 'Items that are unavailable are automatically shown as sold out based on your product availability settings.' The only menu work is a per-product Show online flag, plus optional customer-facing names. SHORTFALL 1 - SERIES AND MARKET, and it is bigger than a product-line split: O-Series is the Kounta Australia/New Zealand line, so the kiosk is not sold in this record's primary market. SERIES AND MARKET, established by the verifier rather than assumed: O-Series is the Kounta lineage and is an Australia/New Zealand line. support.kounta.com 301s to o-series-support.lightspeedhq.com. The O-Series Payment Integrations section is Tyro, Windcave (NZ), Eftpos NZ/Verifone (NZ), Westpac Presto Smart and Smartpay, every one Australian or New Zealand; its Online Ordering partner row is 'Deliverect (Uber Eats, Menulog, Doordash), Bopple, Hey You, LOKE, Me&u, MOBI, Mr Yum, Order Up!, Ritual', likewise; and the string 'United States' occurs in 1 of the 281 O articles, in shared iPad-stand boilerplate. K-Series is the multi-region flagship, documented across the US, Canada, the UK, Europe, Australia and New Zealand. Confirming it on the commercial side, https://www.lightspeedhq.com/au/pos/restaurant/kiosk/ returns 200 while https://www.lightspeedhq.com/pos/restaurant/kiosk/, the /uk/, /ca/ and /nz/ paths all 404, with the US, CA and NZ 404 bodies byte-identical to one another and their stripped text exactly 4,823 characters, identical to a fabricated-path control; and the AU site navigation carries 'Kiosk New' and 'Loyalty New' under Hospitality where the US navigation carries neither. SHORTFALL 2 - NO FIRST-PARTY K-SERIES KIOSK. Tokenised `kiosk` returns 1 hit in 1 of the 537 K-Series articles and it is not a kiosk product: it is a third-party order-profile code, 'Kiosk (if applicable): UEATKI' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/36914000260891-Setting-up-and-using-the-UEAT-integration). K-Series kiosks come from third parties: the complete 450-page partner directory carries exactly two pages with Category: Kiosk, INFI (https://www.lightspeedhq.com/integrations/infi/) and Kurve (https://www.lightspeedhq.com/uk/integrations/kurve/), both 'Compatibility: Lightspeed Restaurant POS (K-Series)'. A prior pass cited Kurve at https://www.lightspeedhq.com/integrations/kurve/, which 404s; that slug was guessed and is corrected here. SHORTFALL 3 - NO ACCESSIBILITY CONFORMANCE ANYWHERE. Tokenised WCAG 0, VPAT 0, 'Section 508' 0 and ADA 0 across all 818 articles; no accessibility clause in the Lightspeed Service Agreement, the Data Processing Agreement or the Privacy Policy; https://www.lightspeedhq.com/accessibility/ 404s and the published Legal index at https://www.lightspeedhq.com/legal/ is a closed list of fourteen documents with no accessibility document among them; and the kiosk article's own configurable surface is an inactivity timeout of 20 to 90 seconds, a logo, a banner image or video, a welcome message and free-text Additional information, with no audio mode, tactile navigation or screen-reader statement. BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is a kiosk or accessibility subject. PARTNER DIRECTORY CENSUS (450 unique slugs, union of the en-US, AU, UK, DE and CH integration sitemaps, 675 URLs). The verifier found the inherited fetch had a 14% hole: 65 of the 450 pages had returned HTTP 429 with no body, so controls had actually run over 385 pages while being reported as 450. All 66 were re-fetched at 200 and the census is now complete at 450/450, 227 of them restaurant-scoped. Over the complete 450: tokenised voice 0, IVR 0, telephony 0, caller 1 (Voicee), Apple Business Connect 0, Apple Maps 1, WCAG 0, VPAT 0, accessibility 0. Exactly two pages carry Category: Kiosk, both Compatibility: Lightspeed Restaurant POS (K-Series): INFI (https://www.lightspeedhq.com/integrations/infi/) and Kurve (https://www.lightspeedhq.com/uk/integrations/kurve/). BOUND LIMIT, disclosed: this public directory is not the whole partner manifest. The K-Series article About the Integration Hub describes a second, in-product directory - 'The Integration Hub is a directory of third-party integrations that work with Lightspeed Restaurant. With hundreds of integrations available...' - reached from the Back Office navigation bar and therefore behind a merchant login, and the O-Series supported-integrations article itself defers to it: 'Find the partners we integrate with by exploring the integration menu from your Lightspeed back office.' No zero over the public directory is a statement about the Hub's contents. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. FALSIFIED BY: a K-Series first-party kiosk article, a Lightspeed Kiosk product page outside /au/, or any published VPAT/ACR. https://o-series-support.lightspeedhq.com/hc/en-us/articles/45638355445275-Setting-up-Lightspeed-Kiosk · retrieved 2026-09-15 adversarially verified
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
Drive-thru exists in this vendor’s documentation only as a renameable order-type label, never as a flow, and the order-typing model is enumerated here. The KDS order type filter "allows you to control what types of orders are displayed on the KDS." and the types themselves are just accounting groups: "These types are based on the accounting groups set up in the Back Office. Dine-In, Delivery, and Pickup are the default accounting groups and can be changed according to your needs." So a merchant may name a type Drive-thru, but nothing attaches to it: the type carries only a display meaning, "Displays the order’s destination to assist tracking and correct delivery.", and the sibling field is the channel, not a lane - "Displays where the order originates, such as online or via a delivery service." The full set of ticket fields (Customer, Order ID, Number of customers, Server, Type, Floor, Order Source, Pickup Time) contains no lane, window or vehicle concept, and the only elapsed-time construct is a service timer, "Wait time is the expected average time to complete an order." There is no order-point/pay-window/pickup-window separation, no lane or tandem-lane sequencing, and no pull-forward or parking-spot assignment. Measured, not quoted: the strings drive-thru, drive thru and drive-through occur zero times across all 546 current en-us K-Series articles and lane occurs zero times in any operational sense; the Restaurant product index carries no drive-thru product; and across the 283 O-Series articles the single occurrence anywhere in the family is a printer-routing example listing drive-thru among order types for sending dockets to specific printers. Note for the record: the vendor’s quick-service marketing page names drive-thru twice, but only in the third person as an industry practice, and a marketing page omitting a feature is not evidence of its absence - that page is deliberately not the citation for this cell. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-09-05 adversarially verified
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
No drive-thru capability exists anywhere in the K-Series product surface. The Supported hardware article enumerates every supported peripheral class (barcode scanners, receipt/label printers, network accessories, cash drawers, payment terminals, KDS, Order Display Screen) - no lane hardware, headsets, or timers. The Sales Reports catalog likewise enumerates its reports (Business, Products, Product Mix, Shifts, Staff, Hourly Performance, Text Messages, Device, KDS Statistics) with no drive-thru or speed-of-service-by-lane report. 'Drive-thru' appears in zero of the 527 help-centre articles. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-05
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
CLAIM, two limbs: a first-party AI voice ordering agent for phone and/or drive-thru that injects orders as POS orders, OR a documented API partner program for third-party voice AI. BOTH LIMBS FAIL, IN BOTH SERIES. LIMB ONE - Lightspeed's AI portfolio is enumerated in its own documentation and none of it is voice or order capture. K-Series: 'The Back Office Lightspeed AI agent pulls sales data from reports in the Back Office and presents it in an easy-to-read format, including charts and graphs. It can also provide answers to support questions by searching the Lightspeed Help Center' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/42676619412251-Understanding-the-Back-Office-Lightspeed-AI-agent) - a Back Office analytics and support chat behind an AI access permission. O-Series: the AI menu importer (https://o-series-support.lightspeedhq.com/hc/en-us/articles/51562172008987-Importing-menu-via-AI-menu-importer) and the AI Menu Pricing Assistant (https://o-series-support.lightspeedhq.com/hc/en-us/articles/53359077249179-Using-the-Menu-Pricing-Assistant). LIMB TWO - the developer programme is generic, not a voice-AI programme: 'The Lightspeed API is available to certified developers. If you pass our certification, we will be able to grant you access to develop your add-on' (https://o-series-support.lightspeedhq.com/hc/en-us/articles/31329349293211-Submit-your-Developer-Application), and the companion 'How to Become a Certified Lightspeed Partner' is a single paragraph pointing at an application form. Per the odoo-pos precedent already in this corpus, verified for this pass, a generic API or partner surface does not satisfy limb two: the rubric asks for a programme FOR third-party voice AI, and no such programme, certification track or named voice partner is published anywhere. BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is a voice or telephony subject. PARTNER DIRECTORY CENSUS (450 unique slugs, union of the en-US, AU, UK, DE and CH integration sitemaps, 675 URLs). The verifier found the inherited fetch had a 14% hole: 65 of the 450 pages had returned HTTP 429 with no body, so controls had actually run over 385 pages while being reported as 450. All 66 were re-fetched at 200 and the census is now complete at 450/450, 227 of them restaurant-scoped. Over the complete 450: tokenised voice 0, IVR 0, telephony 0, caller 1 (Voicee), Apple Business Connect 0, Apple Maps 1, WCAG 0, VPAT 0, accessibility 0. Exactly two pages carry Category: Kiosk, both Compatibility: Lightspeed Restaurant POS (K-Series): INFI (https://www.lightspeedhq.com/integrations/infi/) and Kurve (https://www.lightspeedhq.com/uk/integrations/kurve/). BOUND LIMIT, disclosed: this public directory is not the whole partner manifest. The K-Series article About the Integration Hub describes a second, in-product directory - 'The Integration Hub is a directory of third-party integrations that work with Lightspeed Restaurant. With hundreds of integrations available...' - reached from the Back Office navigation bar and therefore behind a merchant login, and the O-Series supported-integrations article itself defers to it: 'Find the partners we integrate with by exploring the integration menu from your Lightspeed back office.' No zero over the public directory is a statement about the Hub's contents. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. Additional controls over the 818 articles: IVR 0 and telephony 0 in both series in all three modes; AI as a substring scores 4,132 (K) and 2,213 (O) - again, against, available, maintain - and tokenises to Back Office analytics, menu import, pricing and partner product names only. FALSIFIED BY: a Lightspeed voice agent article, or a published voice-AI partner or certification track. https://k-series-support.lightspeedhq.com/hc/en-us/articles/42676619412251-Understanding-the-Back-Office-Lightspeed-AI-agent · retrieved 2026-09-15 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
Per-slot capacity limits exist for the online channel: Order ahead settings include 'Time slot duration: The time in minutes between future orders' and 'Limited orders... In the Orders per time-slot field, enter the number of orders accepted in each time slot duration. For example, accept only five orders every 15 minutes.' Shortfall: no automatic quote-time extension on kitchen load - prep time is changed manually ('From the Restaurant POS app, you can edit prep time to better match current production speed'), and the caps are static per profile, not load-triggered. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-05
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
Order Anywhere service profiles have an 'Order ahead' toggle: 'Allow customers to schedule future orders for pickup or delivery by toggling on this button. This option is not available for the Table profile'; profiles set a 'Custom delivery delay or Custom deadline' in minutes per profile (the per-channel lead time), and future orders are listed by pickup time with a 'Carried forward' reporting treatment. Shortfall: no documentation of a computed fire time that injects the ticket into the KDS/print queue later than receipt. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-09-03 adversarially verified
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
'Customer invoices allow you to manage catering and wholesale orders within Lightspeed POS... manage orders or services that a customer can pay for at a later time' via an Invoice payment method, Accounts Receivable page and per-customer Balance view; separately, 'Customer deposits allow you to accept advance payments for upcoming events and functions... recorded as a positive balance on the customer's profile and remain excluded from daily revenue and sales until they are redeemed' (Creating and applying customer deposits). Shortfall: no quote/proposal workflow and no separate catering order queue or event schedule - catering orders ride the normal POS order flow. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403941107099-Creating-customer-invoices · retrieved 2026-08-05
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
Same evidence as kitchen-order-ready-callback: the KDS 'Ready to collect' status change pushes a notification to installed third-party online ordering integrations, with no POS or tablet action ('no need to update it again on the POS', March 2026 release notes). Not enumerated per marketplace. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-09-03 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
'Understanding void reasons': reasons are created in Back Office (Payment > Refunds and voids) and 'Only POS users with the appropriate permissions can refund or void receipts from the POS'; every void or refund carries a reason, optionally printing an internal receipt, and 'Void reasons display in the Cancellations and corrections report'. Shortfall: reason codes are documented for voids and refunds, not for comps or discounts, and gating is by standing user permission rather than a manager-approval prompt. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657449-Understanding-void-reasons · retrieved 2026-09-03 adversarially verified
Menu, modifiers & pricing engine
Payments & money movement
The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator
payments-processor-choice
Third-party processors are supported and enumerated, but the vendor's own contract mandates against them. The K-Series supported-hardware article carries a Payment terminals and card swipers section which states "Third-party payment processors will provide you with encrypted card readers and payment terminals compatible with their services." and "Lightspeed Support can assist with the integration between third-party payment terminals and Lightspeed Restaurant.", then "Select from the options below to see lists of supported terminals from third-party payment processors." -- five selectable processor tabs (CCV, SIX/Worldline, SumUp, PayPal, Verifone) each opening a model table, including "Verifone VX820", "Yomani Touch XR", "Lane 5000", "SumUp Air", "PayPal Reader" and "Zettle Reader 2", with an explicit exclusion list introduced by "The following PAX terminals are not supported:". The article declares its own hardware scope closed -- "Lightspeed only provides support for the hardware listed in this article." -- so this is an enumerated supported set, not a marketing gesture. Corroborated on the software side by article 1260804605710 Understanding payment types, which makes Third-party payment processors a first-class integrated payment type, and by article 51339829150747, a full setup guide for the PayPal/Zettle reader. SHORTFALL: choice is contractually restricted, not free. Service Agreement section I.5.3 requires a customer who uses the Products, is located in a jurisdiction in which Lightspeed Payments is offered and is eligible for it to use Lightspeed Payments unless Lightspeed agrees otherwise in writing, and section I.5.4 charges a volume-tiered monthly fee to any such customer who processes elsewhere (tiers unretrievable -- they route to regional PDFs on robots-barred pdf.lightspeedhq.com). The supported third-party list is also regional (Switzerland, France, EMEA, APAC), and every terminal Lightspeed itself sells runs Lightspeed Payments only. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-09-05 adversarially verified
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
Neither first-party page carries a rate. The payments page redirects — 'View our competitive processing rates on our pricing page' — and the pricing page publishes software tiers and a $30/screen/month KDS line and no card-processing rate at all. The only published payment figures anywhere are a $15 chargeback fee and two-business-day deposits. https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-02 adversarially verified
Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator
payments-dual-pricing
The Lightspeed Payments FAQ enumerates exactly one card-cost-offset mechanism - surcharging ('Surcharging with Lightspeed Payments is available from the Settings page') - and mentions no dual pricing, no cash discounting and no separate cash/card price storage. Nothing in the payments documentation set (FAQ, Surcharging with Lightspeed Payments, Processing service charges) or the menu pricing docs describes storing two prices per item or printing cash and card totals side by side on the check. Surcharging is the vendor's documented alternative. https://k-series-support.lightspeedhq.com/hc/en-us/articles/15214224728987-Lightspeed-Payments-FAQ · retrieved 2026-08-03
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
All three named elements are documented. Exclusions: 'Debit and prepaid cards (US and Canada)' are excluded from surcharging automatically, alongside card-not-present transactions. Caps: the surcharge must not exceed the processing rate the merchant is charged and 'can never exceed 3%' in the US (2.4% in Canada). Location control: enabled from the settings for the business/location, and 'Surcharging cannot be enabled for locations in the province of Quebec.' Gates worth knowing: Lightspeed Payments only, Australia/Canada/US only, At Sale payment authorization mode only, and Mobile Tap terminals excluded. https://k-series-support.lightspeedhq.com/hc/en-us/articles/12625085075995-Surcharging-with-Lightspeed-Payments · retrieved 2026-08-03
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
Chip and contactless run on a closed certified fleet (Verifone P400+, V400m, e285/e280, Mobile Tap, AMS1, S1F2). Tap to Pay on iPhone documentation names the wallet directly - 'accept Apple Pay, contactless credit and debit cards, and other digital wallets'. Google Pay is named only on the payments product page (grade C), which lists 'American Express, Visa, Mastercard, Diners, Discover, JCB, UnionPay' plus Google Pay and Apple Pay; it is not enumerated in support documentation. https://k-series-support.lightspeedhq.com/hc/en-us/articles/10071706424347-Tap-to-Pay-on-iPhone-with-Lightspeed-Payments · 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
'With Tap to Pay on iPhone, Lightspeed Payments gives you the ability to accept payments directly on your iPhone with no additional hardware required', accepting Apple Pay, contactless cards and wallets. Requirements: iPhone XR or above, iOS 18.4+, a Lightspeed Payments account, Lightspeed Restaurant for iOS 24.2+; enabled under Payment > Payment methods > Lightspeed Payments > Tap to Pay for iPhone. iPhone only; no Android tap-to-pay is documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/10071706424347-Tap-to-Pay-on-iPhone-with-Lightspeed-Payments · retrieved 2026-09-03 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
All three elements documented separately: mobile terminals (Verifone e285/e280, V400m, Mobile Tap, AMS1, S1F2) are carried to the table; 'For payment terminals with a screen, such as the Smart Terminal, customers can tip on the terminal itself' and 'If prompted, the customer confirms the tip amount on the payment terminal'; and the check splits by seat via Distribute by seat before payment. The card never leaves the guest. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities · retrieved 2026-08-02 adversarially verified
Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator
payments-qr-guest-pay
'Scan and Pay allows customers to pay for Order Anywhere orders by scanning the QR code attached to their specific table after their meal. From their mobile device, customers can pay by debit or credit card, split the bill with others, and receive an email receipt' (Order Anywhere Back Office > Settings > Payment settings > Scan and pay). The guest flow ('Scan the unique QR code on your table... Tap Pay the bill', split by amount or by item) is in Placing orders using Order Anywhere; payments sync to the POS and 'the order will be removed from the order management screen automatically when the check is fully paid' when enabled in the order profile. Payment methods also expose 'Initiate payment via QR code'. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803521850-Enabling-payments-for-Order-Anywhere · retrieved 2026-08-05
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
Tips and gratuities handling documented including declared tips; batch/adjust window and an unadjusted-tip manager screen are not. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities · retrieved 2026-08-01
Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator
payments-tip-pooling
Synced tip pools with automated calculation are delivered through the 7shifts partnership, not natively in the POS. https://www.lightspeedhq.com/pos/restaurant/payroll/ · retrieved 2026-08-01
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
The K-Series article Offline POS functionality documents the absence directly and names the alternative. Under Offline limitations, for integrated card payments with a terminal: "Integrated payments (Lightspeed Payments) are not handled in real-time. The actual payment transaction must be handled using the terminal in standalone mode, with LTE/4G connection." And, in both partition scenarios, "Payment terminals without a cell network connection will not function". The documented offline tender set is cash and manual types only, the article listing under Manual payments that cash, check or any custom Manual payment type "can be accepted and recorded in the POS". Store-and-forward exists for ORDER data, not card capture — "the active POS will log all activity and send its stored data once the internet connection is restored". No per-transaction or cumulative offline card limit is offered because no offline card capture is offered. The stated alternative — a 4G-backed terminal run standalone — is what makes this a no rather than an absence. https://k-series-support.lightspeedhq.com/hc/articles/53028167251867 · retrieved 2026-09-05 adversarially verified
Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator
payments-offline-decline-liability
K-Series documents no store-and-forward offline payments mode at all, so neither half of the claim is published. The vendor's documented internet-outage fallback is standalone mode - payments processed directly on the terminal 'as a fallback in case of an internet outage' - and those payments 'do not generate a receipt ID and are reported exclusively in the Payments report'; no offline queue, no post-reconnect decline handling and no failed-offline-payments report appear there, in the Lightspeed Payments FAQ, or in the Troubleshooting Lightspeed Payments article (all retrieved 2026-08-04). The gap is product-specific: Lightspeed documents exactly this for Retail X-Series ('Each payment with the Offline declined status represents a loss') but publishes nothing equivalent for Restaurant K-Series. https://k-series-support.lightspeedhq.com/hc/en-us/articles/5028210082715-Standalone-payments · 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
First-party stored value is a documented product set — Gift cards 2.0: About / Setting up / Using at the POS / Selling online / Importing / Printing. Shortfall: the article addresses neither redemption across every location in a group nor real-time balance tracking, both named in the claim; cross-location gift-card behaviour is unresolved across this record. Selling gift cards online additionally requires Lightspeed Payments. https://k-series-support.lightspeedhq.com/hc/en-us/articles/6339161622427-About-gift-cards-2-0 · retrieved 2026-08-02 adversarially verified
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
On-account charging is native: orders are tendered to the Invoice payment method (code IKDEBT), accumulate on the Back Office Accounts receivable page per customer, show as a running Balance on the customer profile at the POS, and 'Make invoice' generates a single invoice for all of a customer's pending invoice orders, which can then be settled, viewed, and exported (PDF/CSV/XLSX). ID cards can bill 'the guest's consumption through the generated account'. Shortfall: no per-account credit limit setting is documented, and statements are on-demand batch invoices rather than periodic statement runs. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403941259291-Managing-customer-invoices-in-the-Back-Office · retrieved 2026-08-05
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
Split by seat and by covers documented; multi-tender settlement and any split cap are not. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360051089493-Check-splitting · retrieved 2026-08-01
Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.
payments-refund-void-controls
Role-based authorization is documented: per-user-group permissions for 'Order refunds' ('void and refund processed transactions'), 'Partial refunds', 'Order reopen via refund', 'Line voids' ('cancel items that have already been sent to production') and 'Cash drawer access' ('open the cash drawer without processing a transaction'), plus group-scoped discount availability ('define which discounts this user group can apply'). Shortfall: the audit half is not documented as identifying the approver - the Cancellations and Corrections report's columns are Receipt ID, Account, Item, Qty, Amount, Date, Reason and Reason #2 with no user field, and while the Invoices report exposes a per-check Journal 'event log used for auditing purposes', neither approver identity nor immutability is documented for it. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804594730-Managing-POS-user-groups · retrieved 2026-08-03
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
In-product dispute dashboard, not an email chase: 'From the Disputes tab, you can view the status of all current and past chargeback disputes, including the response deadline, current status, reason for the dispute, and total amount of the dispute.' Merchants open a dispute, click Challenge dispute, and 'drag and drop or select any relevant evidence' with typed evidence categories including transaction details and proof of refund. Evidence is gathered by the merchant rather than auto-assembled from the transaction record; the fee is described as a non-refundable chargeback fee without a published amount. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4402294260251-Managing-chargebacks-with-Lightspeed-Payments · retrieved 2026-08-02 adversarially verified
Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator
payments-card-on-file
'By creating an account, customers can add credit and debit cards to a digital wallet in Order Anywhere... payment and contact details will be pre-filled at checkout'; the default card is auto-selected and cards are managed under profile > Wallet. Shortfall: the stored card is usable only inside Order Anywhere online checkout - no documented reuse for phone orders or in-store POS payments (in-store manual entry requires keying the card each time). https://k-series-support.lightspeedhq.com/hc/en-us/articles/6732200120091-Managing-customer-accounts-in-Order-Anywhere · retrieved 2026-08-05
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
Schedule published and faster funding offered. K-Series docs enumerate 'three types of payouts with varying schedules: Scheduled: A scheduled daily payout. Funds are usually paid out within 1-3 business days. Same-day: An instant payout configured to pay out automatically at a set time each day. Funds are paid out within 30 minutes. Instant: An instant payment that you can manually request... Funds are paid out within 30 minutes.' Same-day is a self-serve toggle (Financial Services > Settings > Payouts > 'Enable same-day payout') with a chosen daily time. The companion article 'Getting paid with Lightspeed Payments' publishes the standard schedule in detail: 6 AM local batch cutoff and 'settlements deposited into your bank account within 2 business days after the original transaction,' with a day-by-day settlement table. Priced, not free: instant 1%-1.75% and same-day .5%-1.5% of the payout by region, min $150, max $9,999 per deposit / $15,000 per 24 hours, US/UK/EU/AU and eligibility-reviewed. https://k-series-support.lightspeedhq.com/hc/en-us/articles/28477493132571-Receiving-Instant-Payouts-with-Lightspeed-Payments · retrieved 2026-08-09 adversarially verified
Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.
payments-p2pe-pci4
Lightspeed's own published Attestation of Compliance (ControlCase QSA, Gerald Drake III) covers 'Lightspeed e-commerce and retail Card Tokenization Service (CTS); Lightspeed Cloud Point of Sale Application' and states 'Lightspeed is a PCI DSS Level 1 Service Provider'. On encryption: 'Lightspeed K and L series support P2PE compliant devices and PTS compliant magnetic stripe readers... employ encryption technology that come preconfigured from the payment gateways'. Shortfall: the attestation is PCI DSS v3.2.1, based on a ROC dated January 11, 2024 and signed February 2024 - not the 4.x the claim requires - and 'P2PE compliant' devices are not a PCI SSC validated P2PE solution listing. https://pdf.lightspeedhq.com/documentation/PCI_AOC_R-C-X-K-L-O-G-Payments.pdf · retrieved 2026-08-02 · not refetchable · site policy · graded A when read adversarially verified
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
Operator-configured in Back Office with no vendor involvement: stations are created by name ('Enter a unique name for this KDS screen, with a maximum of 25 characters') and items routed to them - 'Select which items you wish to have routed to this station', with the article's own example being 'you might want the Menu categories > Alcohol items to go to this station if it's for a bar area', or 'All items' for a single-station kitchen. Routing by item and by menu category is documented; order type and revenue center are not, which the claim's or-list does not require. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22168531609499-Setting-up-Kitchen-Display-System-2-0 · retrieved 2026-08-02 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
KDS 2.0 gives an order-level roll-up but no expo or pass role and no cross-station completion gate. Present half: a ticket carries the order’s items and completes only at the order level - "Once all items in the order are picked up, the order is completed and the ticket is moved to the archive" - and the POS receives a consolidated production status, "Changes made in the KDS at production centers are reflected on the POS", surfaced per course as Fired, Sent, Preparing, Ready to collect or Completed. SHORTFALL: the Station Management setting list is closed and contains no expo, pass or aggregator role. The All settings "menu has many more display options available as well as the ability to reset the station to change any properties configured at setup", and the customizable properties under it are exactly "Ticket summary, Order Status, Color theme, Layouts, Language and time, Wait Times," and Routing; the ticket field toggles are likewise enumerated (Customer, Order ID, Number of customers, Server, Type, Floor, Order Source, Pickup Time). Nothing in that set aggregates state across screens. Each screen is an independently configured, independently filtered copy of the ticket rather than a contributor to one shared order state: routing is per-screen item selection - "Similar to the screen when first configuring your KDS, this page can be used to add or remove ordered items that will be sent to this KDS station." - filtering is per screen, "You can configure each KDS screen to filter orders that appear on the screen" by POS device or floor, and configuration does not propagate, "Each station is configured individually." So an operator who splits items across a Grill and a Bar screen gets two tickets that complete independently; consolidation is achievable only by pointing one screen at every item, and withholding completion until every contributing station has bumped is not described anywhere in the sole KDS 2.0 usage document. Scored partial rather than no because the current en-us help centre is a very well-behaved floor but not a proven census, and it demonstrably gates a small number of live articles. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-09-05 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
POS Configurations > Order Management documents 'Coursing options: Assign groups to specific courses to manage course firing and meal pace', 'Automatically fire the first course', and that 'Courses beyond the first are not fired automatically by default'. On the POS, 'When the POS user is ready to have the second course fired, they can tap the Fire course button' (Adding orders in Table Service mode, 360051089273); KDS 2.0 shows 'Tickets on hold or unfired' and the course number. Firing is from the POS (iPad or iPhone); no expo-screen fire is documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804606610-Managing-and-understanding-POS-configurations · retrieved 2026-09-03 adversarially verified
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
KDS timing settings are enumerated and are ticket-level lateness flags, not per-item cook-time pacing: 'Enable Timer... Average: Displays the expected wait time for completed orders... Delayed After: the elapsed time after which KDS will flag a ticket as being delayed... Late after: ...flag a ticket as being late' (orange/red pulse). No per-item cook time field exists anywhere in menu or KDS configuration, and no staggered start/display logic to land items simultaneously is documented in KDS 1.0 or 2.0. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-08-05
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
Order Anywhere service profiles carry a configurable order-volume cap that automatically refuses further orders in a slot once crossed: 'Limited orders: Click this option to restrict the number of orders taken. In the Orders per time-slot field, enter the number of orders accepted in each time slot duration. For example, accept only five orders every 15 minutes,' paired with 'Time slot duration: The time in minutes between future orders.' Crossing the cap defers the customer to a later slot, which paces release of incoming digital orders automatically. Shortfall: the cap applies only to Order ahead (scheduled) orders and is not available on the Table profile, so ASAP orders are unthrottled; there is no ticket-time or kitchen-load trigger; and quoted times are never extended automatically - 'you can edit prep time to better match current production speed' is a manual POS action, as is the Control center 'Online orders enabled' kill switch. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-06
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
Item-level 86 propagates natively to Order Anywhere and Uber Eats: snoozing via the OA-Availability web extension on the POS makes items unavailable online, and 'you can snooze Uber Eats in Order Anywhere... you will need to have item availability activated'; sales restrictions auto-mark items 'unavailable in Order Anywhere (or other supported third-party partners)' at zero stock. Uber Eats ordering can be paused from Integration Hub > Online ordering and delivery > Uber Eats ('use the toggle... to pause or enable ordering'). Shortfalls: DoorDash/Grubhub run through the separate Deliverect (Lightspeed Delivery) product, pause is Back Office not POS/KDS, and no timed auto-reactivation exists for the marketplace pause. https://k-series-support.lightspeedhq.com/hc/en-us/articles/25724049883675-Setting-up-the-Uber-Eats-integration · retrieved 2026-08-05
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
'If you have a third-party online ordering integration installed, a Ready to collect notification is sent to them when you update the status in KDS.' The March 2026 release notes (47746434645275) add: 'Orders marked ready on the KDS now trigger automatic notifications to integrated third-party ordering platforms. There's no need to update it again on the POS' (app version 24.6 or later). Which marketplaces act on the signal is not enumerated. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-09-03 adversarially verified
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
Lightspeed's own KDS 2.0 is operated by 'Double-tapping the ticket' or 'Tapping and holding the ticket' on an iPad; no bump bar is listed in Supported hardware. Bump-bar support is documented only for the partner Fresh KDS integration: 'Support for label printing and bump bar functionality.' Shortfall: partner-delivered, and no supported bump-bar models are named by Lightspeed. https://k-series-support.lightspeedhq.com/hc/en-us/articles/11432070108827-Setting-up-the-Fresh-KDS-integration · retrieved 2026-09-03 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
The Items list view does aggregate: 'When the same item is ordered across many tickets... the KDS can display the ordered items combined together across all of the tickets so the station knows how many of each item needs to be prepared,' with bulk status updates from that view. Shortfall: aggregation is per item only. Modifiers appear as 'Accompanying instructions for each item in the list' - listed per line, never rolled up into a per-modifier count - so a cook cannot read an all-day quantity for a modifier, which is the second half of the claim. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-08-02 adversarially verified
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
Two operator-set thresholds per KDS station with colour escalation: 'Delayed After: This is the elapsed time after which KDS will flag a ticket as being delayed, in minutes. Delayed tickets will pulse with an orange glow' and 'Late after: ... Late tickets will pulse with a red glow.' The claim asks for colour escalation and/or an audible alert; the visual half is documented, audible is not, and no manager-device escalation or speed-of-service report exists. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-08-02 adversarially verified
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
The printer half is documented as an ordered fallback list: 'The first printer listed will be the main printer, followed by fallback printers,' and 'If this printer is turned off or cannot print, the device will attempt to print on the second printer in the list, and so on,' with an optional _BACKUP PRINTER_ header stamped on rerouted tickets. Shortfalls: no failover for a dead KDS screen is documented anywhere in the KDS 2.0 set - the setup article's only guidance when 'a Hub or KDS display disconnects' is to check the network, and a disconnected screen's sync count 'will stall until the connection is restored' - and no article states the no-ticket-loss guarantee the claim requires. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804607010-Managing-printing-profiles · 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
Internet down, LAN up: 'Kitchen Display System: KDS remains function[al] as it connects via the local network.' The limit is named too: if the local network is also lost, 'KDS is not functional as it connects via the local network.' https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 adversarially verified
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
Beyond ticket line text, production instructions ('preparation notes that can be manually added or automatically tied to an item... the POS will prompt the server to include the relevant preparation info') and modifiers flow to production tickets and KDS stations, and KDS ticket content is configurable (Customer, Order ID, Server, Type, Floor, Order Source, Pickup Time toggles). Shortfall: instructions are text notes only - no recipe steps, portioning specs, images, or structured build cards can be displayed at a station. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804656349-About-production-instructions · retrieved 2026-08-05
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
The KDS 2.0 usage article enumerates every element a ticket can render and none of them is a section, half or graphical placement. Ticket Summary is Collection Code, Server, Type, Covers; Ticket Body is course number, item count, per-item action buttons and "List and number of each item in the order with action button"; configurable ticket fields are Customer, Order ID, Number of customers, Server, Type, Floor, Order Source, Pickup Time; the further display axes are seats and Shared items, Notes and Allergens, and courses. Customization renders as plain text choices under the item: "The KDS shows the customer’s specific choice (for example," ... "but not the name of the modifier group or production instruction itself" - so even the modifier group name is dropped, which is the opposite of unambiguous sectioned rendering. Layout options are only Direct line view and Equal view. Upstream there is no fractional model to render (see menu-pricing-fractional-placement, scored no on the modifier engine's own field enumeration), so both the model and the rendering are absent. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-09-05 adversarially verified
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
Un-bumping exists but is capped at five seconds, which is a mis-tap guard rather than recall. The article: "If an item or order ticket is completed accidentally or needs to be redone", "there is a brief window where it can be returned from completed or the archive to an active state." - and then the documented limit, verbatim: "This button appears for five seconds after the completion of an item. Once the five seconds have elapsed, the completion can no longer be undone. Completed tickets can be found in the archive." A second, unbounded path exists but only forward of completion: "Tickets on hold can be restarted by tapping an item in the order". SHORTFALL: after five seconds a bumped ticket cannot be returned to an active state from the KDS, and the KDS’s own printing is status-triggered and automatic - "Once a printing profile is selected, order tickets automatically print when changed to the selected list of statuses" - with no manual per-item reprint control on the screen. Measured, not quoted, because it lives in other documents: reprinting a fired order ticket IS documented, across 13 K-Series articles, and it is production-center-scoped rather than merely order-level - the Receipt actions flow lets a user choose which production centers receive the resend, so selecting only the Bar production center reprints only the items assigned to it, and each copy is stamped with a RE-PRINT marker at the top of the ticket. The refire granularity is therefore the production center, not the individual item, and the recall window is five seconds. Correction for the record: the prior rationale that reprinting is not described in the setup or usage articles is affirmatively wrong and must not be carried forward. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-09-05 adversarially verified
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
When an order is modified from the POS, 'its order ticket will blink with the new information until a user taps on it to confirm the update,' and new orders announce with a bell. Shortfall: the alert is ticket-level with acknowledgement, not the item-level flagging of added, changed or removed lines the claim describes — the cook is told the ticket changed, not which line changed. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0 · retrieved 2026-08-02 adversarially verified
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
A guest-facing status board exists: the Order Display Screen 'displays order numbers on an external screen so customers can see the status of their order, whether it is in progress or ready for pickup. The screen updates automatically as POS users manage orders in the... app or on a Kitchen Display System.' Order Anywhere guests also get email status updates ('Your order confirmation, status updates, and receipt will be sent to the email provided'). Shortfalls: the ODS 'is available as a paid add-on to your existing Lightspeed Restaurant subscription' (claim requires no separate purchase), and no SMS or push notification on bump exists. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4413369711771-About-Lightspeed-Order-Display-Screen · retrieved 2026-08-05
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Waste can be flagged at the POS via wastage discounts - 'Discount indicates wastage: Enable this if the reason for this discount is food waste... Items that have this type of discount applied will appear as a loss in your reports' - and the Inventory module's Wastage feature records waste events with reasons and value and adjusts stock. Shortfall: neither runs on the kitchen/KDS screen; KDS supports ticket actions only, so kitchen staff cannot log waste or remakes with reason codes from the station display. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657089-Understanding-discounts · retrieved 2026-08-05
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
KDS Statistics reports 'the total number of products prepared, the average preparation times for each product, and which products are prepared fastest or slowest', with a per-item Heatmap of production time across a 24-hour timeline and by day of week, plus a Modes distribution of production speeds. Shortfalls against the claim: per-item rather than per-ticket/per-station, no percentile figures, and no slicing by order channel; Lightspeed Tempo adds table-service timing analytics but not kitchen station times. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403156122651-KDS-Statistics · retrieved 2026-08-05
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
Lightspeed Tasks is the product that occupies the daily kitchen task-list slot and it is entirely manual, with a closed manager capability list containing nothing derived from sales. It is a "central task management system that replaces paper lists and whiteboards" in which managers can only "Create, assign, and schedule checklists of tasks", "Configure response types: photo, text, count, signature, or temperature", and "View completion logs and receive checkpoint reports". Checklists are authored by hand and routed by user tag, and the reporting is completion-rate reporting - the daily summary shows "All checklists due the previous day", whether they were completed, and "Overall completion rate" - never a predicted quantity. Nothing in the product reads historical sales, and no count on a task is generated. Measured, not quoted: across the 546-article current en-us K-Series KB the word forecast occurs in exactly three articles and never as a Lightspeed capability - Purchase Reports (historical purchases said to help a restaurant forecast its future purchasing needs), the Deputy integration (third-party labor forecasting) and the Tenzo integration (a third-party restaurant management and data forecasting app). The first-party Produce/production feature is manual recipe batching, and the Back Office Lightspeed AI agent is documented as a reporting and help-centre chat. There is no forecast-driven prep quantity anywhere in the first-party product. https://k-series-support.lightspeedhq.com/hc/en-us/articles/42198624229147-Setting-up-Lightspeed-Tasks · retrieved 2026-09-05 adversarially verified
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
Nothing in the K-Series help centre, the integrations catalogue or the QSR product page describes an in-house driver entity, dispatch board or driver settle-up. The QSR page's delivery language is entirely marketplace aggregation: 'Get orders from UberEats, Foodora or DoorDash sent directly to your POS.' Positive evidence of absence. https://www.lightspeedhq.com/pos/restaurant/quick-service-restaurant-pos/ · 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
The Lightspeed Delivery Dashboard is a channel aggregator, not a dispatch board, and this article closes the enumeration. It is an "aggregated list of all orders placed via the delivery channels linked to your Lightspeed Delivery account." The Orders "page contains the following columns:" and the table names exactly six - Pickup time, Location, Order ID, Channel, Receipt ID, Status. No driver, no driver availability, no elapsed-time-per-order, no run or batch column. The filter set is likewise closed - the article says available filters include Pickup time, Location, Delivery Channel, Order ID, Order status, Receipt ID, Order type and Custom tags, and nothing else. The status vocabulary is enumerated in full - Accepted, Cancel, Canceled, Delivered, Failed, New, Parsed, POS failed, Preparing, Printed, Receipt not found, Received, Rejected - and contains no assigned, dispatched or out-for-delivery state, i.e. no driver ever changes an order's status here. Measured, not quoted: across the 546-article current en-us K-Series KB the word driver appears only as a printer driver plus Uber Direct/Uber Eats courier text, and courier appears only in the Uber Direct and self-delivery articles; K-Series self-delivery is documented as delivery zones, fees, minimums and time estimates, with no driver roster and no run batching. https://k-series-support.lightspeedhq.com/hc/en-us/articles/5780735561883-Viewing-orders-in-the-Lightspeed-Delivery-Dashboard · retrieved 2026-09-05 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
First-party delivery's complete documented feature set is enumerated in the self-delivery release note - 'Self-delivery enables merchants to: Offer delivery service to customers using your own couriers, Create a geographic delivery zone, and Set a delivery time estimate, fee, and minimum order total by delivery zone' - and the matching Delivery settings in Managing Order Anywhere service profiles (zone, fee, minimum, estimated time). There is no dispatch board, no map of stops, and no route sequencing anywhere in the product; courier logistics beyond that are delegated to Uber Direct. https://k-series-support.lightspeedhq.com/hc/en-us/articles/34339315446171-What-s-new-Self-delivery-for-Order-Anywhere · retrieved 2026-08-05
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
No driver-facing app exists. Self-delivery's documented capabilities are limited to 'Offer delivery service to customers using your own couriers, Create a geographic delivery zone, and Set a delivery time estimate, fee, and minimum order total by delivery zone.' No article describes capturing driver GPS or any dispatch screen; for outsourced delivery, couriers belong to Uber Direct/Uber Eats and their position is not surfaced in Lightspeed. https://k-series-support.lightspeedhq.com/hc/en-us/articles/34339315446171-What-s-new-Self-delivery-for-Order-Anywhere · retrieved 2026-08-05
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 areas support free-form map polygons, not just radius: 'Set one or multiple zones to deliver within by clicking Create new... Radius: Choose this option to create a delivery area based on distance. Custom shape: Choose this option to draw a custom delivery area on the map.' Since January 2025, 'you can define multiple delivery zones with customizable fees and minimum order requirements for each area' (What's new: January 2025). https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-05
Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.
delivery-zone-pricing
Per-zone economics are documented for Order Anywhere delivery service profiles: one or multiple zones, each radius-based ('create a delivery area based on distance') or drawn ('draw a custom delivery area on the map'), each carrying 'a delivery fee to be applied to each order', 'a minimum amount an order needs to reach before you'll deliver' and 'an estimated delivery time in minutes to display to the customer'; fulfilment by own staff or Uber Direct. Shortfall: the article never describes address validation or the automatic assignment of an order to its zone from the customer's entered address - the claim's application mechanism is undocumented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-03
Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.
delivery-address-validation
Delivery ordering is gated by map-defined zones: profiles carry one or more delivery areas (radius or custom shape drawn on a map) each with its own fee, minimum order, and time estimate, so a customer's address is resolved against zones at checkout to price and permit delivery. Shortfall: the docs never describe the validation behavior itself - no statement of geocoding provider, rejection/flagging UX for out-of-zone addresses, or address-correction handling. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803546769-Creating-Order-Anywhere-service-profiles · retrieved 2026-08-05
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
No driver entity exists in the product. Self-delivery's enumerated scope is zones, fees, minimums, and time estimates with 'your own couriers'; there is no per-delivery assignment record, no mileage or reimbursement capture, and no payroll export of any kind (labor features are clock-in/out hours plus tip declaration; payroll/scheduling is delegated to the 7shifts integration). Nothing to compute per-delivery compensation from is present. https://k-series-support.lightspeedhq.com/hc/en-us/articles/34339315446171-What-s-new-Self-delivery-for-Order-Anywhere · retrieved 2026-08-05
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
Per-user cash accountability exists via user banks: every POS user has a 'user bank, or wallet... set up by default', counted at shift start/end, with the Shift/User reports computing 'Overage: Dollar value based on the discrepancy between what should be in the cash drawer and what was counted' - so a driver clocked in as a POS user gets a per-person over/short. Shortfall: nothing links orders or deliveries to a driver, so there is no delivery-specific settle-up (orders assigned vs cash collected vs tips owed); it is generic drawer accountability only. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050436394-Managing-cash-drawer-operations · retrieved 2026-08-05
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
Uber Direct is a listed integration; partner UEAT routes to DoorDash Drive and Uber Direct. Whether courier quotes and status return into the POS order record is not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/36914000260891-Setting-up-and-using-the-UEAT-integration · retrieved 2026-08-01
Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator
delivery-daas-fallback
Dispatch mode is a static per-profile choice, not a rule: 'You can choose to offer delivery using your own staff or through Uber Direct' - the profile's Delivery section is configured to one or the other ('Choose Delivery by my staff... or Delivery via Uber Direct'). No overflow, timeout, or zone-based fallback rules exist; the Uber Direct setup article confirms its delivery range is 'a fixed distance dependent on country' and 'cannot be edited'. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-05
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
Uber Eats has a direct K-Series integration. DoorDash and Grubhub reach the POS through Deliverect, which Lightspeed resells as 'Lightspeed Delivery by Deliverect'. https://www.lightspeedhq.com/pos/restaurant-k-series/integrations/ · retrieved 2026-08-01
Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.
delivery-3p-injection
Injection itself is real and real-time: menus sync 'from Back Office to platforms like DoorDash and Uber Eats, then have online orders sent straight to your POS device', and 'Once an order is accepted from the delivery channels, it's sent to your POS device in real time.' Shortfall: the path is Deliverect middleware, not a native Lightspeed integration - the setup procedure begins 'Request a demo from Deliverect', so the operator signs a second contract with a third party, and no cost is published on either side. https://k-series-support.lightspeedhq.com/hc/en-us/articles/25208938481691-Setting-up-the-Deliverect-integration · retrieved 2026-08-02 adversarially verified
Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).
delivery-86-sync
Item-level out-of-stock sync is documented for Order Anywhere and Uber Eats: items snoozed from the POS (OA-Availability web extension) go 'Currently unavailable' online with timed auto-unsnooze, and sales restrictions mean 'When items reach zero quantity, these items are automatically marked as unavailable in Order Anywhere (or other supported third-party partners)... When inventory is restocked, the item automatically becomes available once again'; the Uber Eats FAQ confirms snoozing Uber Eats items via Item availability. Shortfalls: modifier/item-option 86 is not documented (DoorDash's standard requires item-option 86ing), and DoorDash/Grubhub availability runs through the separate Deliverect product, not this mechanism. https://k-series-support.lightspeedhq.com/hc/en-us/articles/10724827631259-Setting-up-and-using-Item-availability · retrieved 2026-08-05
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
Uber Eats can be paused from inside Lightspeed: 'The Back Office allows you to pause Uber Eats orders. Navigate to Integration Hub > Online ordering and delivery > Uber Eats and use the toggle... You can also pause orders from the Manage Uber Eats page by clicking Pause orders.' First-party profiles pause from the POS itself (Order Anywhere web extension > Order Profiles > Pause orders). Shortfalls: no timed auto-reactivation for either pause, marketplace pause is Back Office (browser) rather than the POS app, and DoorDash/Grubhub pausing is not documented (they ride Deliverect). https://k-series-support.lightspeedhq.com/hc/en-us/articles/25724049883675-Setting-up-the-Uber-Eats-integration · retrieved 2026-08-05
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
Order-level payment reconciliation exists: the Online orders report (Operations > Online orders) shows per-order 'Online payment: The total amount paid on the order via the third-party integration', 'Payment over/under: The total amount over or under if the total in the integration doesn't match the total from the POS', 'Total corrections for period', and per-order failure reasons. Shortfall: nothing matches marketplace payout deposits to recorded sales or itemizes commission/marketing fees - reconciliation stops at order-amount differences (the documented payment difference tolerance, default $0.02). https://k-series-support.lightspeedhq.com/hc/en-us/articles/38418918961819-Understanding-the-Online-orders-report · retrieved 2026-08-05
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
Failed injections are visible per order in two places: the Lightspeed Delivery (Deliverect) dashboard statuses include 'Failed: There was an issue sending the order to Lightspeed', 'Parsed', 'POS failed', 'Receipt not found', and 'Rejected'; the Order Anywhere Orders page shows 'Failed: An error prevented the order from being received at the POS' and the Back Office Online orders report exposes 'Issue: The reason that the order was unsuccessful'. Shortfalls: no per-channel connection-status view and no proactive alerting on failure is documented - the operator must be watching the dashboards. https://k-series-support.lightspeedhq.com/hc/en-us/articles/5780735561883-Viewing-orders-in-the-Lightspeed-Delivery-Dashboard · retrieved 2026-08-05
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
Guests get order-status visibility but not driver tracking: 'Your order confirmation, status updates, and receipt will be sent to the email provided', and the Order Anywhere account Orders page shows 'Any current orders that are pending or in preparation' plus failed orders 'so there is no question whether an order went through or not'. Shortfall: no branded tracking page with courier position or delivery progress exists for self-delivery or Uber Direct orders - status is order-state emails and the account history page only. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803553189-Placing-orders-using-Order-Anywhere · retrieved 2026-08-05
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
Quoted times are operator-entered constants, documented as such: 'Order preparation time: Choose to set an average preparation time in minutes or omit any time estimate', and per delivery zone 'Estimated delivery time: Enter an estimated delivery time in minutes to display to the customer.' Load-responsiveness is manual: 'you can edit prep time to better match current production speed. Edited prep times only affect orders placed after the time was changed.' No automatic adjustment from kitchen load, driver availability, or drive time exists. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-05
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
The claim requires documented offline behavior for delivery; Lightspeed documents the opposite precondition: 'Before you begin fulfilling orders from Order Anywhere, make sure that: Your POS device is online and connected to the internet.' The OA order lifecycle (Pending until 'received by the POS', Failed 'if the Restaurant POS app is not open') shows online orders do not flow during an outage, and no article addresses cash delivery orders, driver assignment, or settlement offline. General offline guidance is one line - 'most basic order-taking functions will still work offline' (Troubleshooting network issues) - with nothing delivery-specific. https://k-series-support.lightspeedhq.com/hc/en-us/articles/23267765915547-Fulfilling-orders-from-Order-Anywhere · retrieved 2026-08-05
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
Order Anywhere is first-party and branded - setup includes 'Upload a banner image or logo to display at the top of your customer-facing Order Anywhere page' and separate light and dark mode logos - and it 'integrates directly with the Restaurant POS app' for takeaway, pickup and in-restaurant table orders. Commission-free is a vendor product-page claim ('0% commission, no marketplace fees', 'fully branded experience with a white-label solution'), grade C. It is a paid add-on to any Lightspeed Restaurant subscription, not a Starter-tier-only charge, and a custom domain is not documented - the page is Lightspeed-hosted. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803518310-Setting-up-Order-Anywhere · retrieved 2026-08-02 adversarially verified
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
Lightspeed’s guest ordering product is positioned as explicitly app-free, and the vendor says so as a selling point: "Let guests view your menu, order and even pay by scanning a QR code. No need for them to download an app." Order Anywhere is described throughout as a web channel ("Generate unique QR Codes" linked to specific menus or tables; "Support takeout, delivery and online ordering from the table (scan & pay), all from one platform"), and the branding pitch is about the web experience rather than a store listing: "Ensure brand consistency", "Display your menus online in a professional digital layout." The claim excludes a mobile web page explicitly, so this cannot be scored partial. Corroborated on three further legs, measured rather than quoted. First, Lightspeed’s site-wide global product index - the same navigation rendered on every page of lightspeedhq.com, including its 404 page, so it is a catalogue rather than one page’s feature list - lists the Restaurant products as Delivery, Order Anywhere, Advanced Insights, Inventory, Tableside, Payments, Accounting, Kitchen Display System, Pulse, Reservations, Tasks, Tempo, Capital, Benchmarks & Trends, Workforce Management & Payroll, Hardware, Integrations, Enterprise and Pricing, with no consumer app product, while the Golf vertical in the same index does carry a "Website & App" product. Second, independently of that navigation, the www sitemap union enumerates roughly sixty /pos/restaurant/ pages including one per Restaurant product and contains no app page, while it does carry /golf/website-app/ and /golf/website-app/custom-websites/. So Lightspeed demonstrably sells a branded consumer app in another vertical and does not in Restaurant. Third, across the 546-article current en-us K-Series help centre every App Store and Google Play reference is to the staff-facing Lightspeed Restaurant POS app or to iPadOS update hygiene; there is no consumer app of any kind. Grade C because the cited document is a vendor feature page written to sell; the app-free line is nonetheless an affirmative vendor statement, not an absence. https://www.lightspeedhq.com/pos/restaurant/order-anywhere/ · retrieved 2026-09-05 adversarially verified
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
Accounts with tokenized cards are documented: customers 'log in with your Google or Apple account or with the email address and password' used at sign-up, can 'add credit and debit cards to a digital wallet in Order Anywhere' and save contact info, with payment and contact details 'pre-filled at checkout' and the default card auto-selected. Shortfalls: saved delivery addresses and one-tap reorder of a previous order are not documented anywhere in the Order Anywhere account articles - the claim's reorder element is absent from the vendor's description. https://k-series-support.lightspeedhq.com/hc/en-us/articles/6732200120091-Managing-customer-accounts-in-Order-Anywhere · retrieved 2026-08-03
Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator
digital-upsell-engine
Algorithmic and configurable suggestions exist in Order Anywhere: 'Use smart upselling, powered by AI, to recommend specific products... These recommendations are based on your sales data and automatically update daily' (Popular items, 3-8 recommendations, requires 150+ orders in past 21 days), and operators can override by 'removing dishes you don't want to feature or pinning high-margin items, daily specials or surplus stock' (Menu > Menu Upsells, July 2026). Shortfall: no attach-rate reporting on the suggestions is documented anywhere in OA reports. https://k-series-support.lightspeedhq.com/hc/en-us/articles/50574509323291-Understanding-Menu-upsells-in-Order-Anywhere · retrieved 2026-08-05
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
Scheduled orders with per-slot caps: Order ahead supports 'Maximum days ahead', 'Time slot duration: The time in minutes between future orders', and 'Limited orders... enter the number of orders accepted in each time slot duration. For example, accept only five orders every 15 minutes' - full slots stop accepting orders. Release to the kitchen is also paced: a future pickup order syncs to the POS 'at the selected pickup time minus your preparation time and a few additional minutes' (Fulfilling orders from Order Anywhere), with a POS Future orders tab (Later today / Tomorrow / Future upcoming). https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-05
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
Pickup/delivery/dine-in/curbside are documented for the UEAT partner integration; the same breadth for first-party Order Anywhere is not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/36914000260891-Setting-up-and-using-the-UEAT-integration · retrieved 2026-08-01
Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.
digital-qr-table
Documented end to end: 'Open the restaurant's Order Anywhere page by scanning the specific QR code assigned to your table', tipping ('Select a tip option or enter a custom tip amount in the Tip section'), payment choice ('Card to pay online or Pay before leaving to pay in person'), and splitting both ways - 'To split the bill by amount, click By amount' and 'To split the bill by item, click By item and select the items you'd like to pay for.' Scan and Pay lets guests settle a table order after eating without waiting for a server. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803553189-Placing-orders-using-Order-Anywhere · retrieved 2026-08-02 adversarially verified
Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator
digital-kiosk
CLAIM: vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI AND unattended EMV payment. Three conjuncts; two are met and one fails, which is why this is partial and not no. SERIES: everything below is O-SERIES ONLY. MET - SAME MENU AND MODIFIER LOGIC: 'The kiosk displays all products enabled for visibility in the Online products section. To configure customer-facing names and visibility settings, navigate to Back Office > Products > Online products', variants and option sets are selected on the kiosk itself, and sold-out state follows 'your product availability settings' (https://o-series-support.lightspeedhq.com/hc/en-us/articles/45638355445275-Setting-up-Lightspeed-Kiosk). MET - UNATTENDED EMV: setup pairs the kiosk to a Lightspeed Payments terminal - 'tap Pair on the payment terminal to connect it to the kiosk. Once the payment terminal is paired, the kiosk status displays Ready to accept orders' - and the guest step is 'Tap, swipe, or insert your card on the payment terminal', card-present with no staff involvement. The documented payment restriction is a scope limit, not an EMV limit: 'Cash, promo codes, gift cards, and other third-party payment methods are currently not supported on the kiosk.' NOT MET - ACCESSIBILITY-COMPLIANT UI: the kiosk's entire configurable surface is enumerated in that article as an inactivity timeout of 20 to 90 seconds, a logo, a banner image or video, a welcome message and free-text Additional information. There is no audio mode, no tactile navigation, no screen-reader statement and no conformance claim, and tokenised WCAG, VPAT, ADA and 'Section 508' all read 0 across both help centres. SHORTFALL 2 - SERIES AND MARKET: this is an O-Series app and O-Series is the Kounta Australia/New Zealand line, so the kiosk is not available in this record's primary market. SERIES AND MARKET, established by the verifier rather than assumed: O-Series is the Kounta lineage and is an Australia/New Zealand line. support.kounta.com 301s to o-series-support.lightspeedhq.com. The O-Series Payment Integrations section is Tyro, Windcave (NZ), Eftpos NZ/Verifone (NZ), Westpac Presto Smart and Smartpay, every one Australian or New Zealand; its Online Ordering partner row is 'Deliverect (Uber Eats, Menulog, Doordash), Bopple, Hey You, LOKE, Me&u, MOBI, Mr Yum, Order Up!, Ritual', likewise; and the string 'United States' occurs in 1 of the 281 O articles, in shared iPad-stand boilerplate. K-Series is the multi-region flagship, documented across the US, Canada, the UK, Europe, Australia and New Zealand. https://www.lightspeedhq.com/au/pos/restaurant/kiosk/ returns 200; the US, UK, CA and NZ paths 404, the US/CA/NZ 404s having stripped text of exactly 4,823 characters, identical to a fabricated-path control. The AU navigation carries 'Kiosk New' and 'Loyalty New'; the US navigation carries neither. K-Series has no first-party kiosk at all: tokenised `kiosk` is 1 hit in 1 of 537 K articles and it is the third-party order-profile code UEATKI. BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is a kiosk subject. PARTNER DIRECTORY CENSUS (450 unique slugs, union of the en-US, AU, UK, DE and CH integration sitemaps, 675 URLs). The verifier found the inherited fetch had a 14% hole: 65 of the 450 pages had returned HTTP 429 with no body, so controls had actually run over 385 pages while being reported as 450. All 66 were re-fetched at 200 and the census is now complete at 450/450, 227 of them restaurant-scoped. Over the complete 450: tokenised voice 0, IVR 0, telephony 0, caller 1 (Voicee), Apple Business Connect 0, Apple Maps 1, WCAG 0, VPAT 0, accessibility 0. Exactly two pages carry Category: Kiosk, both Compatibility: Lightspeed Restaurant POS (K-Series): INFI (https://www.lightspeedhq.com/integrations/infi/) and Kurve (https://www.lightspeedhq.com/uk/integrations/kurve/). BOUND LIMIT, disclosed: this public directory is not the whole partner manifest. The K-Series article About the Integration Hub describes a second, in-product directory - 'The Integration Hub is a directory of third-party integrations that work with Lightspeed Restaurant. With hundreds of integrations available...' - reached from the Back Office navigation bar and therefore behind a merchant login, and the O-Series supported-integrations article itself defers to it: 'Find the partners we integrate with by exploring the integration menu from your Lightspeed back office.' No zero over the public directory is a statement about the Hub's contents. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. https://o-series-support.lightspeedhq.com/hc/en-us/articles/45638355445275-Setting-up-Lightspeed-Kiosk · retrieved 2026-09-15 adversarially verified
Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.
digital-group-ordering
Lightspeed ships a feature literally named Group Ordering and this article documents it end to end as a staff-side counter tool, which is the vendor's stated alternative to a shareable group cart. It "helps your staff process and prepare orders for groups of customers ordering at the counter" - a server rings each guest at an assigned table, and the only thing that is grouped is the kitchen ticket, on a timer: "the system will send the Group Order to the kitchen at the same time and on the same ticket." Payment is per guest and immediate, not pooled or split at the end: "Process your customer’s payment and complete the sale as usual." The whole configuration surface is two timers - "Set the max time between orders" and "Set max time since first order" - with no participant link, no per-person or total spend cap, and no shared cart. Every element of the claim (shareable link, multiple participants adding to one order, spend cap, split or single payment) is absent from the one feature the vendor named for this job. https://k-series-support.lightspeedhq.com/hc/en-us/articles/11395178539931-Setting-up-and-using-Group-Ordering · retrieved 2026-09-05 adversarially verified
Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator
digital-catering-portal
Order Anywhere's order types are exhaustively enumerated - 'Select order type: Click this button to switch between Pickup and delivery, Table, and Menu browsing profiles' - and none is a catering flow; no catering menu, minimum, lead-time, quote, or deposit setting exists in OA. The deposits and customer-invoice features live in the POS/Back Office, not in any guest-facing ordering portal, and Lightspeed's restaurant integration directory lists no catering-portal partner (checked 2026-08-05). https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles · retrieved 2026-08-05
Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator
digital-voice-ai-phone
CLAIM: AI voice phone ordering, native OR via a named certified partner, that answers inbound calls and injects the completed order into the POS without staff transcription. NOTHING SATISFIES IT IN EITHER SERIES. NATIVE: none - see order-capture-voice-ai; the documented AI is the K-Series Back Office analytics agent, the O-Series AI menu importer and the O-Series AI Menu Pricing Assistant. NAMED PARTNER: the only telephony partner Lightspeed names anywhere is Voicee, and Lightspeed's own page for it describes the opposite of order injection - 'Lightspeed Caller ID Cloud-Phone with Advanced Call Flow Features... You can now answer every call with any personalised greetings', with the POS-side feature listed as 'Find POS Orders - Find a pending order in your Lightspeed POS and alert your staff that they're calling about a particular order', under 'Compatibility: Lightspeed Restaurant POS (O-Series)' (https://www.lightspeedhq.com/au/integrations/voicee/, re-fetched 200 on 2026-09-15). Finding a PENDING order and alerting staff is a lookup, not an agent that answers the call and writes a new order. Voicee is vendor-documented rather than directory-only: it is named in the Marketing row of Lightspeed's own O-Series partner roster, which introduces itself 'This guide lists the partners Lightspeed can be integrated and provides links to relevant support guides' (https://o-series-support.lightspeedhq.com/hc/en-us/articles/31329284546971-Lightspeed-Restaurant-supported-integrations); that table has no telephony or voice partner in any other row, and no kiosk row at all. SERIES: the K-Series flagship has no telephony surface - across all 537 K articles tokenised telephony 0, IVR 0, voice 0, and `caller` tokenises to ONE hit which is anti-phishing advice, 'Scammers can use technology to alter the number they appear to be calling from, so that a legitimate business number shows up on your caller ID' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/23340222300059-Following-security-best-practices-to-protect-your-business-online). BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is a telephony subject. PARTNER DIRECTORY CENSUS (450 unique slugs, union of the en-US, AU, UK, DE and CH integration sitemaps, 675 URLs). The verifier found the inherited fetch had a 14% hole: 65 of the 450 pages had returned HTTP 429 with no body, so controls had actually run over 385 pages while being reported as 450. All 66 were re-fetched at 200 and the census is now complete at 450/450, 227 of them restaurant-scoped. Over the complete 450: tokenised voice 0, IVR 0, telephony 0, caller 1 (Voicee), Apple Business Connect 0, Apple Maps 1, WCAG 0, VPAT 0, accessibility 0. Exactly two pages carry Category: Kiosk, both Compatibility: Lightspeed Restaurant POS (K-Series): INFI (https://www.lightspeedhq.com/integrations/infi/) and Kurve (https://www.lightspeedhq.com/uk/integrations/kurve/). BOUND LIMIT, disclosed: this public directory is not the whole partner manifest. The K-Series article About the Integration Hub describes a second, in-product directory - 'The Integration Hub is a directory of third-party integrations that work with Lightspeed Restaurant. With hundreds of integrations available...' - reached from the Back Office navigation bar and therefore behind a merchant login, and the O-Series supported-integrations article itself defers to it: 'Find the partners we integrate with by exploring the integration menu from your Lightspeed back office.' No zero over the public directory is a statement about the Hub's contents. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. FALSIFIED BY: a Lightspeed partner page or help article describing a telephony partner that answers calls and writes orders into the POS. https://www.lightspeedhq.com/au/integrations/voicee/ · retrieved 2026-09-15 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
There is no drive-thru mode to attach voice AI to: no drive-thru workflow, hardware, or configuration appears in any of the 527 help-centre articles; the supported-hardware catalog enumerates peripherals with no lane displays or headset systems; and neither the help centre nor the public integration directory names any drive-thru voice partner (checked 2026-08-05). https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-05
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
329th, NEW SURFACE + BOUND. (1) The K-Series API is PUBLISHED anonymously as a downloadable OpenAPI 3.1 spec: https://api-docs.lsk.lightspeed.app/source.json (the 'Download source JSON' link on api-docs.lsk.lightspeed.app, a host a prior note recorded as 403 - it is 200 to curl with a browser UA). 147,211 bytes, openapi 3.1.0, info.title 'Lightspeed Restaurant K Series API', 74 paths, 1,345 component schemas, 11 webhooks. Nonsense control: /source-zzz.json returns the 90,508-byte SPA shell and a 404, the real spec begins {"openapi":"3.1.0", so it is not a soft-200. This spec contains the Order Anywhere (first-party ordering) configuration surface as the `orli-configuration*` schemas. (2) The help centre was re-paged in full and BOUNDED: k-series-support.lightspeedhq.com Help Center API, 538 articles, 2,500,944 chars of stripped text, retrieved 2026-09-18. An href fixpoint over all 538 bodies yields 238 referenced article ids; 13 are not in the listing; probed individually via /api/v2/help_center/en-us/articles/<id>.json, 12 return 404 (dead links) and exactly ONE returns 401. That one gated id (1260804605370) is identified from its three referrer contexts as 'Editing or deleting accounting groups' (401 in en-us/fr/nl/de, 404 in es/it) - an accounting-group admin topic, so the unmeasured residue of the census is one article and it is not about ordering channels. CONTROLS (tokenised, word-boundary, case-insensitive; known-positive 'restaurant' returned 32 on the same normaliser): over the 538 KB articles - sms 3 (Gift cards 2.0 FAQ, Setting up Lightspeed Tasks, Understanding PCI compliance; none an ordering channel), 'text message' 4 (3 in a security-hygiene article; 1 is the 'Text Messages Report', which the article itself defines as 'all text messages used on the POS device ... any subitem with the Item entered by user feature enabled ... such as "extra toppings" ... what your front staff communicates to the kitchen' - POISON: it is a kitchen-note report, not a guest channel), texting 0, whatsapp 0, chatbot 0, conversational 0, text-to-order 0. Over the 147 KB OpenAPI spec - sms 0, chat 0, whatsapp 0, conversational 0, 'text message' 0. The spec's ordering enumerations are CLOSED and have no text channel: orli-configurationServiceType = [DELIVERY, TAKEOUT]; orli-configurationMerchantContactType = [EMAIL, WEB, PHONE, TWITTER, INSTAGRAM, FACEBOOK, TRIPADVISOR, GOOGLE_MY_BUSINESS, TIKTOK, WEBSITE, YELP, YOUTUBE, SNAPCHAT, PINTEREST]. Over 7 freshly fetched Lightspeed Restaurant marketing pages (pos/restaurant/, /features/, /order-anywhere/, /customer-retention-loyalty/, /delivery/, whats-new-lightspeed-restaurant/; 1,700,329 raw bytes) - sms 0, texting 0, whatsapp 0, chatbot 0, conversational 0. Over the 246 Lightspeed marketplace listings on disk, 101 of which declare Restaurant compatibility: sms appears only as reservation confirmations ('will receive an email and sms confirmation', covermanager, K/L-Series) and loyalty marketing blasts ('Kangaroo's email platform, SMS, push notifications', kangaroo-rewards) - notification, never order capture; a partner registry does not carry the vendor's feature anyway. VERDICT: no. The vendor's own complete documentation and its complete published API contain no conversational SMS/chat ordering or text-a-link order channel of any kind. Retrieved 2026-09-18. https://api-docs.lsk.lightspeed.app/source.json · retrieved 2026-09-18 adversarially verified
Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator
digital-google-order
'Order with Google allows customers to search for your restaurant on Google and click Order Pickup or Order Delivery to place orders via your Order Anywhere website,' and 'your Order Anywhere menu and images will also sync for customers to view in your Google profile, even if they don't click your ordering link.' Prerequisites: a Google Business Profile 'registered under the same name and address' as the Lightspeed account and at least one Pickup and delivery service profile; only one menu can be linked to Google per business location. Gate: rides on Order Anywhere, a paid add-on. The claim's parenthetical 'Preferred by Business' designation is not mentioned in the article. https://k-series-support.lightspeedhq.com/hc/en-us/articles/39777750001051-Google-integrations-for-Order-Anywhere · retrieved 2026-08-04
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
CLAIM: 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. This is a claim about VENDOR provisioning, consistent with every other record in this corpus; an operator can always add a custom action in Apple Business Connect by hand pointing at their own Order Anywhere URL, and that would not make it a Lightspeed capability. LIGHTSPEED BUILT THE GOOGLE EQUIVALENT AND PUBLISHES NOTHING FOR APPLE, IN EITHER SERIES. The K-Series first-party ordering product, Order Anywhere, has a dedicated article for exactly this class of channel: 'A Google Business Profile controls how your business appears in Google products, such as Search and Maps. You can sync business hours, social media links, and other details directly from Order Anywhere to Google' and 'Order with Google allows customers to order from your restaurant in Google Search and Maps', with step-by-step provisioning through Order Anywhere Back Office > Integrations (https://k-series-support.lightspeedhq.com/hc/en-us/articles/39777750001051-Google-integrations-for-Order-Anywhere). The enumeration is taken from the publisher's own section taxonomy, not from prose: the K-Series section 'Integrations for Order Anywhere' holds exactly two articles, the Google one and Setting up Uber Direct for Order Anywhere. Apple is nowhere in that surface. SERIES: both. 'Apple Business Connect' and 'Apple Maps' each read ZERO across all 537 K and 281 O articles in substring, token and stem mode. BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is a discovery or ordering-placement subject. PARTNER DIRECTORY CENSUS (450 unique slugs, union of the en-US, AU, UK, DE and CH integration sitemaps, 675 URLs). The verifier found the inherited fetch had a 14% hole: 65 of the 450 pages had returned HTTP 429 with no body, so controls had actually run over 385 pages while being reported as 450. All 66 were re-fetched at 200 and the census is now complete at 450/450, 227 of them restaurant-scoped. Over the complete 450: tokenised voice 0, IVR 0, telephony 0, caller 1 (Voicee), Apple Business Connect 0, Apple Maps 1, WCAG 0, VPAT 0, accessibility 0. Exactly two pages carry Category: Kiosk, both Compatibility: Lightspeed Restaurant POS (K-Series): INFI (https://www.lightspeedhq.com/integrations/infi/) and Kurve (https://www.lightspeedhq.com/uk/integrations/kurve/). BOUND LIMIT, disclosed: this public directory is not the whole partner manifest. The K-Series article About the Integration Hub describes a second, in-product directory - 'The Integration Hub is a directory of third-party integrations that work with Lightspeed Restaurant. With hundreds of integrations available...' - reached from the Back Office navigation bar and therefore behind a merchant login, and the O-Series supported-integrations article itself defers to it: 'Find the partners we integrate with by exploring the integration menu from your Lightspeed back office.' No zero over the public directory is a statement about the Hub's contents. Uberall, a location-marketing and listings partner among the 65 pages that had gone unread, names no map platform and no ordering action on its Lightspeed page - it is reviews, social presence and location marketing. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. Apple tokenises 237 hits / 83 docs in K and 199 / 44 in O and is entirely devices (iPad, iPhone, iPadOS, iOS, App Store), Apple Pay, Apple Wallet loyalty cards and Apple Support links. A phrase probe for 'Order Food' fires ONCE, in the O-Series refunding article, and it is a false positive welded by the probe's own whitespace handling out of 'made-to-order food and drinks', so the real count is zero. FALSIFIED BY: an Apple Business Connect or Apple Maps article in either help centre, or an Apple entry in the Order Anywhere Integrations menu. https://k-series-support.lightspeedhq.com/hc/en-us/articles/39777750001051-Google-integrations-for-Order-Anywhere · retrieved 2026-09-15 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
Native loyalty instruments (punch, VIP, gift, ID cards) are QR vouchers redeemed by scanning at the POS; nothing accrues or redeems inside the first-party digital flow. The Order Anywhere account is enumerated as wallet cards plus contact info and email preferences - no loyalty balance - and the gift-card FAQ is explicit: 'Can a customer pay with a gift card for an order placed through Order Anywhere? No, customers cannot currently use K-Series gift cards to pay for an order placed through Order Anywhere.' Apple Wallet passes store cards but no in-checkout accrual/redemption is documented; richer loyalty is delegated to Marsello. https://k-series-support.lightspeedhq.com/hc/en-us/articles/6339630673435-Gift-cards-2-0-FAQ · retrieved 2026-08-05
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
329th, NEW SURFACE + BOUND. Same bounded census as digital-sms-ordering: the k-series-support.lightspeedhq.com Help Center API re-paged to 538 articles / 2,500,944 chars on 2026-09-18, href-fixpoint bounded (238 referenced ids, 13 absent, 12 of them 404 dead links and exactly one 401 - id 1260804605370, identified from its referrers as 'Editing or deleting accounting groups'), plus the NEW anonymous OpenAPI 3.1 spec at https://api-docs.lsk.lightspeed.app/source.json (147,211 bytes, 74 paths, 1,345 schemas, 11 webhooks; nonsense control /source-zzz.json = 404 SPA shell), plus 7 Lightspeed Restaurant marketing pages (1,700,329 bytes). CONTROLS (tokenised, word-boundary, case-insensitive): in the KB, subscription 52 / subscriptions 15 - every one the MERCHANT's own plan ('About subscriptions and billing invoices', 'Managing and paying subscriptions and billing invoices', device licences, module subscriptions for KDS/Accounting/Order Anywhere); recurring 24, of which 20 are 'Setting up recurring orders', a SUPPLIER purchase-order scheduler ('Recurring orders automate your regular purchases ... orders will be sent automatically ... emailed to the supplier'), the rest chargebacks and a Tasks release note; membership 2, both the ID-cards pair, and 'About ID cards' scopes them to identification only - 'ID cards are a scannable badge for your customers that can be printed or sent digitally. These cards can be used to identify customers in your membership program or customers who have an account that allows them to pay at a later date ... contact our support team to have a batch of cards added to your account' (no price, no billing period, no renewal, no entitlement); memberships 0, 'meal plan' 0, entitlement 0, 'paid tier' 0; tier/tiers 1 hit in the whole KB and it is the third-party Marsello loyalty integration ('offering exclusive perks through VIP tiers ... visit Marsello') - a partner product, not a platform-managed subscription. In the OpenAPI spec: membership 0, recurring 0, and the single 'subscription' hit is lsk-reservation-serviceBackofficeOnlineReservationSubscriptionDto, i.e. 'Configuration for online reservation subscription emails' - POISON, staff email notification opt-in. In marketing: subscription 1 ('Lightspeed Restaurant's pricing varies relative to the subscription you want to use' - the merchant's plan) and recurring 1 ('automated recurring orders' - stock replenishment); membership/memberships 0. POISON NAMED: subscription = the merchant's own billing; recurring = supplier purchase orders and reservation emails; membership = a scannable ID badge; tier = a third-party loyalty app. VERDICT: no. No guest-facing recurring billing, per-period entitlement or paid loyalty tier is managed anywhere in the K-Series platform, on a bounded census of the vendor's own documentation and its complete published API. Retrieved 2026-09-18. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4404650374299-About-ID-cards · retrieved 2026-09-18 adversarially verified
Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.
digital-promo-parity
Promotions are defined per channel in separate engines with different mechanics and availability: POS discounts are configured in Back Office Settings > Discounts (with codes, QR application, wastage flags), while Order Anywhere promotions (BOGO, item discount, profile-wide discount) are created separately in the OA Back Office Offers module and 'are only available in Europe, the Middle East, and Africa'; Uber Eats promotions must be 'set up in Uber Eats'. Nothing defines an offer once for POS, kiosk, and digital with channel eligibility controls. https://k-series-support.lightspeedhq.com/hc/en-us/articles/41912627014939-Creating-promotions-with-Order-Anywhere · retrieved 2026-08-05
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
Bulk self-serve export is documented and unrestricted: Customers > Customer list > Export - 'All data will export by default, so deselect any information you wish to exclude from the file', with file-format choice; Guest book lists can likewise 'export key data to your marketing software'. Shortfall: no published statement that the operator owns the guest records was found - data rights live in the Trust Center DPA (About data privacy and security), which the help centre references without an ownership assertion. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657189-Importing-or-exporting-customer-data · retrieved 2026-08-05
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
The AOC covers the Cloud Point of Sale Application and Card Tokenization Service at Level 1, and Lightspeed's position is that cardholder data is handled by assessed providers rather than the restaurant's own page. Shortfall: the attestation is v3.2.1 (ROC January 11, 2024), so by construction it does not evidence the client-side script-integrity requirements 6.4.3 and 11.6.1 that took effect 31 March 2025; and 3DS support is nowhere stated for Order Anywhere - the AOC's scope form lists '3-D Secure Hosting Provider' only as one of its printed checkbox options. https://pdf.lightspeedhq.com/documentation/PCI_AOC_R-C-X-K-L-O-G-Payments.pdf · retrieved 2026-08-02 · not refetchable · site policy · graded A when read adversarially verified
Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator
digital-surcharge-transparency
The vendor's own surcharging article excludes digital channels outright: 'Card-not-present transactions (e.g. Order Anywhere and manual entry)' are listed among the transaction types that will not include surcharges, so the POS surcharge configuration cannot carry to first-party digital ordering at all. No dual-pricing mode exists anywhere in the payments docs, and the Processing service charges article describes POS order profiles and manual buttons only, never Order Anywhere. The claim's channel-parity premise is positively contradicted for the one surcharge mechanism Lightspeed offers. https://k-series-support.lightspeedhq.com/hc/en-us/articles/12625085075995-Surcharging-with-Lightspeed-Payments · retrieved 2026-08-03
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
Guest book (Advanced Insights, NA/AU/NZ, sales-activated) 'automatically creates a customer profile with each credit card transaction and updates the profile when the customer returns', tracks 'number of visits across locations', and documents merge behavior: 'If a guest returns... and pays using a different credit card with the same name, their check data and credit card payments sync with their original profile.' Shortfalls: card-based identity only ('excludes guests who pay with cash'), it is a separate profile store from Back Office customer profiles and Order Anywhere accounts, and no phone/email dedup across POS, online ordering, and kiosk is documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/7340976689051-Guest-book · retrieved 2026-08-05
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
The only automatic guest-identity mechanism K-Series documents is Guest book, and its stated scope excludes marketplace orders: 'Guest book uses card data to create unique guest profiles. It automatically adds customers who use a credit card at your restaurant and excludes guests who pay with cash or other tenders.' A DoorDash, Uber Eats or Grubhub order is paid on the marketplace and arrives via the Deliverect integration as an externally-paid ticket - no card is processed at the restaurant, so it falls under the documented exclusion. The Deliverect setup article says nothing about guest identity, and the manual Customers profiles attach only when staff select them on an order. Gates on Guest book itself: part of Advanced Insights, North America/Australia/New Zealand only, enabled through a Sales Account Manager. https://k-series-support.lightspeedhq.com/hc/en-us/articles/7340976689051-Guest-book · retrieved 2026-08-04
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
K-Series includes a native 'Loyalty cards module' with VIP (automatic discount when scanned), GIFT, PUNCH ('a buy-x-and-get-y-for-free program', e.g. five coffees then a free one) and ID cards. Shortfall: punch count is the only accrual model; points-per-dollar and spend tiers are not native (the Loyalty section's program integrations are Marsello and Toggle), and card batches must be requested from Lightspeed Support rather than configured self-serve. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4404649891099-About-Loyalty-cards · retrieved 2026-09-03 adversarially verified
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
No native tiers: the built-in loyalty instruments are VIP/gift/punch/ID card batches with no status levels. Tiers arrive only via the documented Marsello integration - 'Marsello streamlines customer engagement by integrating loyalty programs... awarding points for purchases, and offering exclusive perks through VIP tiers.' Shortfall: requires a separate Marsello subscription, and automatic promotion/demotion on rolling-window spend is not documented even in Lightspeed's integration article. https://k-series-support.lightspeedhq.com/hc/en-us/articles/24012819812891-Setting-up-the-Marsello-integration · retrieved 2026-08-05
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
The offline article states the behaviour: 'Cloud-based services: Services like gift card processing and K-series loyalty programs are unavailable' while the internet is down. Shortfall: a single line that does not separate lookup, accrual and redemption, or say whether accrual is queued for later posting. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 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
A precedence rule is documented but fixed, not configurable: 'Item discounts and BOGO promotions take priority over profile-wide discounts for items with the same SKU. Profile-wide discounts do not apply to delivery fees.' POS discount settings (Understanding discounts) expose codes, accounting-group scoping and amount limits but no exclusive-vs-combinable flags or application-order configuration. Shortfall: no operator-configurable stacking/precedence engine on either surface. https://k-series-support.lightspeedhq.com/hc/en-us/articles/41912627014939-Creating-promotions-with-Order-Anywhere · retrieved 2026-08-05
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
Dynamic audiences exist; offer issuance to them does not. Guest book supports rule-built lists ('Build your own list based on customer or ticket criteria, such as a customer's number of visits'), and 'If you collect customer email addresses, you can also contact customers from a list' or 'export key data to your marketing software.' Shortfall: no native mechanism issues a redeemable offer/discount to a segment - offer targeting requires the Marsello integration, and Guest book itself is Advanced Insights-gated (NA/AU/NZ). https://k-series-support.lightspeedhq.com/hc/en-us/articles/7340976689051-Guest-book · retrieved 2026-08-05
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
Two automatic segments plus a computed value score ship with Guest book: 'By default, Guest book automatically includes the Best Guests and Recent Guests lists' (top 100 by spend; most recent visitors) and an 'Estimated Lifetime Value... prediction based on a customer's past behavior.' Shortfalls: no at-risk/lapsed/regular lifecycle segments are computed - anything beyond the two defaults is an operator-built rule list - and the whole feature is Advanced Insights-gated (NA/AU/NZ, activated via sales). https://k-series-support.lightspeedhq.com/hc/en-us/articles/7340976689051-Guest-book · retrieved 2026-08-05
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
No native triggered campaigns exist - Campaigns (Advanced Insights) is a passive date-range sales snapshot, and Daily Digest is a fixed summary email. Lifecycle marketing is delegated to the documented Marsello integration ('rewarding your customers with personalized incentives to keep them coming back'). Shortfall: requires a Marsello subscription, and Lightspeed's own article does not detail which automations (birthday, win-back) Marsello provides. https://k-series-support.lightspeedhq.com/hc/en-us/articles/24012819812891-Setting-up-the-Marsello-integration · retrieved 2026-08-05
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
Advanced Insights Guest book is a segmentation tool, not a send engine. It "automatically creates a customer profile with each credit card transaction and updates the profile when the customer returns to your restaurant.", and of what may then be done with the list it says "You can also create a guest list to segment and export key data to your marketing software." - the documented pattern is handing the list to a third-party ESP. The single outbound sentence is unelaborated: "If you collect customer email addresses, you can also contact customers from a list." No template, schedule, audience builder or send mechanism is documented for it. SHORTFALL, three parts. One, the only guest-facing channel is email; there is no guest-facing SMS. Measured, not quoted, because it lives in another document: a K-Series gift-card FAQ article asks whether a gift card can be sent via SMS text and answers no, offering a workaround instead - the vendor denying guest SMS send in its own words. SMS does exist elsewhere in the product, as staff task-due notifications in Lightspeed Tasks, so the accurate statement is that guest-facing SMS is absent, not that SMS is absent. Two, there is no campaign send engine at all: across the 546-article current en-us KB the strings newsletter, Mailchimp and email marketing occur zero times, and the Advanced Insights Campaigns feature is retrospective analytics of a promotional period, not a sender. Three, the module is a sales-gated regional add-on that a European buyer cannot purchase - "Advanced Insights is currently available to Lightspeed Restaurant customers in North America, Australia, and New Zealand. To get access to this feature, contact your Sales Account Manager or" Lightspeed Support. Loyalty and engagement marketing are otherwise handed to a third party (Marsello). https://k-series-support.lightspeedhq.com/hc/en-us/articles/7340976689051-Guest-book · retrieved 2026-09-05 adversarially verified
Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.
guest-loyalty-consent-management
Consent exists as one boolean on the customer record: "Contact permissions: When enabled, this customer agrees to receive email communications from the restaurant. When disabled, the customer will not receive emails." Revocation is a staff toggle: "To change whether the customer receives email receipts and other email communications, toggle Allow email notifications." The article also instructs "Always ask for permission before entering a customer’s contact information in Lightspeed Restaurant." SHORTFALL: consent is captured for the email channel only -- the enumerated profile fields include Primary and Secondary phone number but no SMS or phone consent flag -- and no consent timestamp and no source-of-consent field appear anywhere in the enumerated customer profile settings. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804605810-Managing-customers-in-the-Back-Office · retrieved 2026-09-05 adversarially verified
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
There is no SMS sending through the platform to register: guest communications are email-only (order status emails, emailed gift/loyalty cards - 'Can I send a gift card via SMS text? No'), no SMS marketing product exists in the help centre, and '10DLC', 'A2P', and 'campaign registry' appear nowhere in the corpus (searched 2026-08-05). With no SMS channel, the platform neither handles nor documents A2P 10DLC brand/campaign registration. https://k-series-support.lightspeedhq.com/hc/en-us/articles/6339630673435-Gift-cards-2-0-FAQ · retrieved 2026-08-05
Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator
guest-loyalty-campaign-attribution
Campaign measurement is a date-window comparison, not redemption attribution: an Advanced Insights campaign is 'a snapshot of your sales data during special events, promotions, or holidays' reporting total sales/visits, average sale, 'the number of new vs. repeat customers, and the profiles of your top spenders', with comparison 'to the average sales for the same day of the week from the prior year.' Shortfalls: nothing ties a specific redeemed offer to check totals or computes incremental lift beyond the prior-year baseline; Advanced Insights-gated (NA/AU/NZ), data 48h delayed, one campaign per location. https://k-series-support.lightspeedhq.com/hc/en-us/articles/7341353071131-Campaigns · retrieved 2026-08-05
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
Self-serve, no fee, no ticket: Customers > Customer list > Export - 'All data will export by default, so deselect any information you wish to exclude from the file. Select the File format... Click Export and the download will start automatically.' Per-customer transaction history exports from Payment > Customer invoices in 'PDF, CSV, and XLSX' (Managing customer invoices), Guest book lists export to marketing software, and the partner API adds Financials/receipts endpoints. Contact PII (name, email, phone) is part of the customer profile export. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657189-Importing-or-exporting-customer-data · retrieved 2026-08-05
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
Order Anywhere collects post-order reviews and routes by score: with a Google Business Profile connected, guests are invited to leave reviews, low/ordinary feedback stays in the OA reviews inbox ('gather valuable feedback, address concerns'), and 5-star responses are pushed onward - the reputation dashboard reports 'OA 5-star redirects: The total number of reviews from Order Anywhere pushed to Google' and a 'Ratings breakdown... comparing the amount of 5-star reviews made directly on Google and the amount of times Order Anywhere redirected a 5-star review to Google.' Setup is Order Anywhere > Integrations > Google Business Profile (November 2025 release). https://k-series-support.lightspeedhq.com/hc/en-us/articles/39777750001051-Google-integrations-for-Order-Anywhere · retrieved 2026-08-05
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
K-Series does have a first-party loyalty product, but it has no referral mechanic. 'The Loyalty cards module included with Lightspeed Restaurant K Series allows you to offer discount, gift, punch, and ID cards to customers', and the module's card types are a closed enumeration of four instruments: VIP ('automatically add a discount to the customer's order when scanned at the POS'), GIFT ('a voucher loaded with a specific monetary amount'), PUNCH ('a buy-x-and-get-y-for-free program') and ID ('used to create a customer account by billing the guest's consumption through the generated account'). The configurable rules on those instruments are closed field tables too: punch = purchase threshold, qualifying item/group, reward item/group, validity dates, offer description; VIP = name, validity from/to, discount, item-category include/exclude filter, per-order item cap. None carries a referral code, a referrer field or first-order attribution. A tokenised grep of all 537 en-us help-centre articles (2026-09-15) returns zero hits for 'referrals' and 'advocacy', and the single 'referral' hit is a Zenchef reservation field that the article says 'is not visible in Lightspeed Restaurant'. Per-guest referral codes, first-order attribution and two-sided rewards are therefore not native; where a merchant gets them at all they come from the Marsello or Toggle partner integrations, which are the whole of the help centre's 'Partner integrations > Loyalty' section. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4404649891099-About-Loyalty-cards · retrieved 2026-09-15 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
Apple Wallet passes exist for loyalty instruments: 'customers can easily manage their punch cards, VIP cards, and gift cards in Apple Wallet. Merchants can create electronic loyalty cards or gift cards for customers and email them a QR code to add the card to their Apple Wallet' (Feb 2024). Shortfalls: Google Wallet is not mentioned, and push-updated balances on the pass are not documented (guests cannot even self-check gift-card balances per the Gift cards 2.0 FAQ). https://k-series-support.lightspeedhq.com/hc/en-us/articles/34338126103195-What-s-new-Loyalty-cards-in-Apple-Wallet · retrieved 2026-08-05
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
Per-guest locate/export/delete primitives exist: the Customers page lets you 'export customer data, view their transaction history, and make changes to or delete customers' (About customers), the customer-list export is field-selectable, and Order Anywhere guests can self-delete accounts ('Delete my account... Deleted accounts cannot be restored'). A DPA and data-retention policy are published in the Trust Center (About data privacy and security). Shortfall: no DSAR-framed workflow, and deletion propagation to Guest book profiles, card batches, or Marsello marketing records is not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657189-Importing-or-exporting-customer-data · retrieved 2026-08-05
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
K-Series does have a first-party loyalty product - "The Loyalty cards module included with Lightspeed Restaurant K Series allows you to offer discount, gift, punch, and ID cards" (About Loyalty cards; VIP/GIFT/PUNCH/ID) - and it ships reactive card-integrity controls, but none of the preventive redemption controls the claim names. PRESENT: per-card revocation/locking, a last-used filter and a per-card lifecycle record. Every card-search article carries the same two filters - "Revocation status: If you know whether the card has been locked or not, you can make an appropriate selection here" and "Last activity: You can filter your results by the time when the card was last used" - and the screen is entered "to find a specific punch card, for example, to edit or lock it" (Searching for certain punch cards; byte-identical tables in Searching for VIP cards, Searching for certain ID cards and Searching for gift cards). Managing ID cards publishes the action and the log: "you can revoke an ID card in the Back Office ... Find the ID card you wish to revoke and click Revoke card", "A revoked card is no longer valid for the customer to use", Last activity "Options are Never, Last month, Last day, and Last year", and "Click on the UUID in the Back Office to review the card's lifecycle, including when it was linked to a customer, when it was sent to the customer's email, and any revocations." SHORTFALL, four parts. (1) No redemption-velocity or frequency limit exists to configure: the punch batch rule set is published as a closed field table ("Configure the rules for your punch card batch. For a description of each field, view the following table") holding only the quantity threshold, the qualifying item/item group, the reward item/group, "This offer is valid from XX to XX" and "Offer description" - no per-guest cap, cooldown or approval step. The VIP table ("For a description of each form field, see the table below") is Name, "Validity period From", "Validity period To (Excluded)", Discount, an item-category include/exclude filter, and "Filter rule (... up to): Determines the number of items on an order that will benefit from the discount" - a per-check item cap, not a velocity control. (2) Redemption at the POS is an unapproved staff action - "Tap the item on the left for which you want the discount to apply. Select the Punch Card discount from the popup" (Using punch cards at the POS) and "Scan the QR code for a VIP card in the Restaurant POS app to automatically apply the associated discount" (Using VIP cards at POS) - and the POS user permission table ("Check the box beside each permission you wish the user to have"; the eight published groups are Report access, Available discounts, Receipts and tickets, Cancellations and voids, Orders, Payments, Shifts, Configurations) carries no manager-approval or second-authorisation permission and nothing scoped to loyalty. (3) The lifecycle view is not established as a REDEMPTION audit log: its enumerated events are linking, emailing and revocation, and no article states that a redemption records the POS user who applied it, so employee self-redemption is neither flagged nor attributable. (4) One conjunct is vacuous rather than refuted - there is no native points balance (punch count is the only accrual model, per guest-loyalty-accrual-models), so "manager approval on manual point adjustments" has no object. Measured over a self-fetched 537-article en-us help centre census (Help Center API, 2026-09-15; robots.txt read whole - User-agent: * does not bar /hc/*/articles/ or the articles listing): "velocity", "cooldown", "self-redemption" and "manager approval" each occur zero times word-boundary. POISON: "audit" has 10 hits and NONE is loyalty - SOC 2 reports, German TSE and Quebec WEB-SRM tax audits, and About Hours' "Audit button [which] provides a detailed overview of the employee activities - for instance, when the cash drawer was manually opened", a cash/labour trail that would read as a loyalty audit log to a bare substring search; "override" resolves to menu upsells, an item-price permission and a cash-drawer float; "cap" is a surcharge cap and an iPad stand; "pin" is the 4-6 digit POS login PIN and "pinning" menu items, not an approval gate. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4404650173467-Searching-for-certain-punch-cards · retrieved 2026-09-15 adversarially verified
Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator
guest-loyalty-ai-offer-recommendation
A shipped, documented AI feature exists under the Back Office Offers menu: "Use smart upselling, powered by AI, to recommend specific products to customers in your menu." "These recommendations can be managed through the Upsell Manager in the Back Office." It is data-gated - "You must have 150+ overall orders in the past 21 days in order to use automated menu upsells." - and self-refreshing: "These recommendations are based on your sales data and automatically update daily once enabled." This is a configured product feature, not a roadmap statement. SHORTFALL: the model chooses menu placement, not an offer, an audience or a send time, and it is not personalised. The sole documented control is a Popular items toggle - "Boost sales and guide customers to best sellers with smart recommendations." and "Toggle on Popular items to display up to 8 of your best-selling menu items." - whose output is a single aggregate best-seller list: "Best sellers display at the top of your Order Anywhere menu. The minimum number of recommendations to display is 3 and the maximum is 8." Every guest browsing the Order Anywhere menu therefore sees the same recommendations, computed from aggregate sales volume rather than from any individual’s history. So of the three things the claim names: offer content is satisfied only weakly, as the selection of which items to promote; target audience is structurally absent rather than merely unselected; and there is no send timing because there is no send. Measured, not quoted: the other first-party AI surface, the Back Office Lightspeed AI agent, is documented as a reporting and help-centre chat that presents Back Office sales data and answers support questions, and generates no offer. https://k-series-support.lightspeedhq.com/hc/en-us/articles/50574509323291-Understanding-Menu-upsells-in-Order-Anywhere · retrieved 2026-09-05 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
Native first-party stored value: Gift cards 2.0, a paid add-on ('Gift cards are a paid add-on. To purchase this feature for your account, contact your Sales Account Manager or the Lightspeed Sales team in your region'). Balances DO attach to a first-party guest record. Back Office > Customers > Gift cards opens an Edit Gift Card page whose field table reads 'Customer - Use this field to assign a new or existing customer to the gift card', alongside balance, Withdraw/Refill transaction history and a 'Customer status' filter; the POS issue flow requires 'Link customer' and warns 'To receive an online gift card, your customer must have an email address assigned to their customer profile'. Customer profiles are a native K-Series object (Creating a customer profile, Editing a customer profile, Managing customers in the Back Office, and Guest book, which 'automatically creates a customer profile with each credit card transaction'). Shortfall: the claim's second conjunct, redemption across all locations of the brand, is not documented for Gift cards 2.0. The 'generated cards are visible at all sites, so you don't generate cards for just a certain location' note and 'Cards can be used at all locations, no matter what location generated them originally' appear only in the LEGACY card-batch articles and in Managing ID cards, not in the nine-article Gift cards 2.0 set, which says only that the online gift-card web store must be enabled per location and that the statistics dashboard filters by location. Gift cards also cannot pay for an Order Anywhere order ('No, customers cannot currently use K-Series gift cards to pay for an order placed through Order Anywhere'). https://k-series-support.lightspeedhq.com/hc/en-us/articles/6339505673243-Managing-gift-cards-2-0-in-Back-Office · retrieved 2026-09-15 adversarially verified
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
'Employees clock in and out of the Restaurant POS app daily to start and end their shift', authenticating with 'your PIN code or place your QR code in front of your device's camera to scan it' - PIN or badge-equivalent, on the same iPad or iPhone that runs service, with no separate time-clock hardware. Permissions distinguish staff who must clock in before using the POS from kitchen users who can only clock in and out. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050309174-Clocking-in-and-out · retrieved 2026-08-02 adversarially verified
Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator
labor-photo-punch-verification
Clock-in authentication methods are enumerated and photo capture is not among them: 'If prompted, enter your PIN code or place your QR code in front of your device's camera to scan it. Note: Add or change employee PIN or QR codes by editing POS users in the Back Office' - the same two credentials (or none) apply at clock-out and login. No photo-at-punch or facial verification option exists anywhere in POS user or time-clock configuration. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050309174-Clocking-in-and-out · retrieved 2026-08-05
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
'Clocking in/out: Staff can clock in and out, with time entries stored locally', and the active POS will 'send its stored data once the internet connection is restored'. Shortfall: nothing describes reconciliation, duplicate suppression, or what happens to punches taken on a passive device that loses the LAN. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 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
API exposes user groups, permissions and per-business-location access. Per-action granularity (void/comp/price change/report access) is not enumerated publicly. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-01
Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.
labor-manager-override-audit
After-the-fact audit surfaces exist: the Invoices report opens a per-check Journal view - 'an event log used for auditing purposes and for tracking all actions performed on the selected check' - and Back Office devices expose an Activity events log of 'basic actions performed on a POS device (such as a POS user opening a sales period or clocking in)'. Shortfalls: no manager-override or per-transaction approval flow is documented at all (permissions are granted per user group, not approved case by case), neither log is documented to identify an approver distinct from the acting user, immutability is nowhere stated, and the Cancellations and Corrections report carries no user column. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403197629595-Invoices-report · retrieved 2026-08-03
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
Scheduling is delivered through the 7shifts partnership, not inside the platform holding the timekeeping data. https://www.lightspeedhq.com/pos/restaurant/payroll/ · retrieved 2026-08-01
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
Sales and labor forecasting exists but is produced by 7shifts consuming Lightspeed sales data, not a native Lightspeed feature. https://www.lightspeedhq.com/pos/restaurant/payroll/ · retrieved 2026-08-01
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 real-time manager surfaces enumerate their metrics and labor cost percentage is not among them: Pulse's live info boxes are 'Orders, Covers, Voids, Discounts, Comps, Order Average, Cover Average, Table turn time, Refunds, Sales per labour hour' ('Sales per labour hour: The amount of sales generated per clocked in employee hour'). No wage-rate field exists anywhere in Back Office labor docs (hours + tip declaration only; pay rates live in 7shifts/Planday integrations), so labor cost as % of sales cannot be computed or displayed, in real time or otherwise. https://k-series-support.lightspeedhq.com/hc/en-us/articles/29496064755099-About-the-Lightspeed-Pulse-App · retrieved 2026-08-05
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
The clock-in flow is documented step-by-step (select name, PIN/QR, confirm user shift, optional drawer count) with no warning or block of any kind, and no overtime threshold exists anywhere in Back Office configuration - 'overtime' appears in zero of the 527 help-centre articles. K-Series labor is limited to punches, hours ('All hours worked by employees can be managed from the Back Office'), and reports; scheduling/labor-compliance is delegated to the 7shifts integration ('hiring, training, scheduling, and paying'). https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050309174-Clocking-in-and-out · retrieved 2026-08-05
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
The K-Series time-capture lifecycle is enumerated end to end in this article and consists of shift start and shift end only: "Employees clock in and out of the Restaurant POS app daily to start and end their shift." The clock-out sequence is listed step by step and ends at "Tap Yes on the pop-up asking you to end your user shift." -- there is no break punch, no jurisdictional meal or rest rule set, no attestation prompt and no missed-break or premium-pay flag. "All hours worked by employees can be managed from the Back Office." K-Series ships no scheduling module at all; rostering and labour compliance are delegated to partner platforms (7shifts, Deputy, Push Operations, Workforce, Tanda). https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050309174-Clocking-in-and-out · retrieved 2026-09-05 adversarially verified
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
This article enumerates the entire POS user record and the entire permission set. "Create a dedicated POS user account for every employee that will need access to the Lightspeed Restaurant app." The stored identity and access fields are username, first and last name, email, and a login credential -- "PIN code: Assign a PIN code that the user must use to log in to the POS. This PIN code can be 4-6 digits.", "Visibility: The user is visible in the POS." There is no date of birth, no age and no minor status on the record, so no age-based maximum hours, prohibited time window or school-day limit can be expressed; the permission list that follows governs report access, discounts, receipts, refunds and orders only. With no scheduling module in K-Series, neither half of the claim (enforcement at scheduling and at clock-in) has anywhere to live. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804594690-Managing-POS-users · retrieved 2026-09-05 adversarially verified
Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.
labor-tip-pooling-rules
Automated tip-pool calculation is a 7shifts capability synced with Lightspeed, not native POS logic. https://www.lightspeedhq.com/pos/restaurant/payroll/ · retrieved 2026-08-01
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
Per-employee tip records are documented: tip declaration prompts at clock-out ('enter the amount of tips to declare... The declared tip amount should be the total you leave with across all payment methods'), declarations 'cannot be changed later', and the Labor Report shows 'employee-specific data, including tips and service charges, alongside everyone's hours worked', with business-wide earned and declared totals in the Business Report. Shortfall: pool contribution and distribution amounts are never recorded - pooling happens outside the system ('Factor in any tips you receive from, or pay out to, other staff'; declared tips 'will differ from their earned amount when they pay out tips to others') - and no per-shift tip-detail export is documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities · retrieved 2026-08-03
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
Declared tips are a single collapsed figure, explicitly across all tender types: "Servers should enter the total tips they took home via all payment methods after paying out tips to other staff, and non-server employees should enter their total tips received." and "Tips can only be declared when clocking out, and declaration amounts cannot be changed later." Lightspeed produces no payroll or tax-filing output and says so: "Report declared tips to the tax authority for your region as required." and "Speak with a tax professional to ensure you follow the correct rules for declaring, distributing, and reporting tips in your region." The named tip outputs are the Labor, Business and Receipt reports; there is no cash-versus-charged qualified-tip split, no Treasury tipped-occupation code and no W-2 Box 12 TP or Box 14b construct anywhere in the article. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities · retrieved 2026-09-05 adversarially verified
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
The vendor payroll page routes payroll processing and payroll support to 7shifts, and restricts it to 'businesses based in the US only.' Scheduling, shift swaps, tip-credit automation and sales/labour forecasting on that page are 7shifts capabilities, not Lightspeed ones. https://www.lightspeedhq.com/pos/restaurant/payroll/ · retrieved 2026-08-01 adversarially verified
Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).
labor-payroll-export-formats
The vendor's integrations page lists a Payroll category naming 7shifts, Atlas, Planday, Push Operations, Restaurant Accounting Services Inc and Restaurant365 - more partners than the record previously credited. Shortfall: the page is a marketing directory and no first-party documentation states which fields cross the boundary. The claim requires timecards, wages and tips to export in documented formats, and nothing documents whether tips or wage rates transfer at all; none of the major payroll processors the claim names as examples (Gusto, ADP, Paychex, QuickBooks Payroll) appear in the list. https://www.lightspeedhq.com/pos/restaurant-k-series/integrations/ · retrieved 2026-08-02 adversarially verified
Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator
labor-shift-swap-workflow
Employees update availability and swap shifts — via 7shifts, not natively. https://www.lightspeedhq.com/pos/restaurant/payroll/ · retrieved 2026-08-01
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 Staff Performance report breaks the table down 'by the employees that worked that date' with per-employee Gross/Net sales, Tips, Covers, Cover average, Orders, Order average (average check), Refunds, Discounts, Voids, Comps, Service charges and Losses, filterable by user, user group, shift, and interval; Advanced Insights adds Servers reports and the Daily Digest shows per-employee discount usage. Shortfall: no item/category attachment-rate metric, and void/comp figures are dollar totals rather than rates. https://k-series-support.lightspeedhq.com/hc/en-us/articles/40994945471515-Understanding-the-Staff-Performance-report · retrieved 2026-08-05
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
Inventory add-on includes recipes with costing plus a 'Produce' batch-production module implying prep items. Multi-level sub-recipe rollup and automatic recalculation on ingredient cost change are not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407511552155-Creating-and-managing-recipes · retrieved 2026-08-01
Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.
inventory-unit-conversion-yields
The unit chain is documented across two Inventory add-on articles. Purchase-to-count: packaging formats carry 'the number of units contained within this packaging type', and on a purchase order 'the total quantity of items is automatically calculated in terms of the base units... if you order a case, 24 bottles will be added to your inventory' (About Items). Count-to-recipe: 'Decrease in stock level = Quantity used in the recipe / Total capacity of one stock unit' - using 60ml from a 1L bottle decrements stock by 0.06 (Stock levels). Shortfall: no yield or waste percentage exists anywhere in the set - the conversion is straight division with no raw-to-usable trim loss, and the only yield concept is an optional expected-yield field on made-in-batches recipes. Gate: requires the Inventory add-on (purchasable on all tiers). https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407517612699-Stock-levels · 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
'Discrepancy reports within Inventory allow you to compare your theoretical stock with the actual stock levels, reflecting your most recent stock counts' for a chosen start/end period, per item: Theoretical Stock Level/Value ('after all stock movements recorded'), Last Counted level/value, 'Variance Qty' and 'Variance Value', plus Purchased Qty/Value, 'Consumed Qty: The total quantity of the item that was consumed in recipes during the selected time period, including batched and Made to order', Batch Yield, Wasted, and Transferred columns - variance in both units and currency, derived from POS-sales recipe consumption, counts, and receipts. https://k-series-support.lightspeedhq.com/hc/en-us/articles/20537741099419-Discrepancy-reports · retrieved 2026-08-05
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
Depletion on sale is documented, not merely marketed: 'When a customer orders one of these items, it will automatically be assembled using its specified ingredients, and your inventory will update accordingly,' with a stated conversion between stock units and recipe measures. Shortfall: the trigger is a recipe-linked item sale only. Modifier-driven depletion - the explicit second half of the claim - is not mentioned anywhere in the recipe or stock documentation, and no article states the depletion latency, so 'near real time' rather than batch is not established. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407511552155-Creating-and-managing-recipes · retrieved 2026-08-02 adversarially verified
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
Threshold-triggered auto-86 exists at item level: 'Sales restrictions can be used to monitor inventory quantities. When items reach zero quantity, these items are automatically marked as unavailable in Order Anywhere (or other supported third-party partners)... When inventory is restocked, the item automatically becomes available once again' (counter set via POS long-press > Availability > Limited). Shortfalls: the trigger is a per-item POS-button counter, not component-ingredient/recipe depletion from the Inventory module, and coverage of third-party menus is limited to 'supported' partners (Uber Eats via Item availability; DoorDash/Grubhub ride Deliverect). https://k-series-support.lightspeedhq.com/hc/en-us/articles/10724827631259-Setting-up-and-using-Item-availability · retrieved 2026-08-05
Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.
inventory-count-modes
Stock management supports monitoring quantities/values, reorder thresholds and inventory audits. Distinct full/spot/recurring cycle-count modes with separate variance history are not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407509542043-Stock-management-Inventory · retrieved 2026-08-01
Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.
inventory-mobile-count-offline
Counting is multi-device and concurrent - 'Multiple employees can count together by each resuming the same stock count from different devices... real-time updates across all devices ensure everyone stays coordinated. Changes save automatically every few seconds' with draft resume and per-location item lists. Shortfalls: the documented count flow is search/scroll entry with no barcode or QR scanning (supported barcode scanners are for adding items to orders at the POS), and offline counting with sync-on-reconnect is not documented - the real-time sync model presumes connectivity. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407510354715-Performing-stock-counts · retrieved 2026-08-05
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
Purchase-order transmission is email, and only email: "Create purchase orders (PO) within the Inventory module to quickly assemble a list of items your restaurant needs and send them directly to your vendor via email to place an order." The final step is "Click Send email to email the purchase order, or click X to forgo the email if purchase orders are placed through other means (such as a phone call to your supplier)." The article names the alternative to its own channel as the supplier website, not an electronic link: "If you order items from your suppliers through other means, such as a supplier website, you can still receive those items into inventory by creating a PO and opting to skip the email." No named broadline distributor, no catalog sync, no electronic invoice return. Sysco, US Foods, Performance Food Group and EDI occur zero times in the 546-article K-Series and 283-article O-Series corpora on disk. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407569259547-Creating-purchase-orders · retrieved 2026-09-05 adversarially verified
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
Native Inventory purchase orders are manual entry (create, place, receive; no scan/ingest option in About Purchase). Invoice ingestion arrives via the documented MarketMan integration - 'a cloud-based inventory and supplier management system... including inventory, purchasing, recipes, vendor payments' - whose invoice product uploads 'via photo, email, or PDF' and extracts line items, matches them to the ingredient list, and flags price changes (marketman.com/page/restaurant-invoice-management-system, retrieved 2026-08-05). Shortfalls: requires a separate MarketMan subscription, and the extracted ledger lives in MarketMan (daily sync), not Lightspeed's Inventory module. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22675539589787-Setting-up-the-MarketMan-integration · retrieved 2026-08-05
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
Price history is tracked per item across invoices: Purchase Reports show 'the goods you've purchased, the quantities ordered, price changes over time, and the suppliers', and each item's History page has 'a graph [that] depicts the changes in cost price for the selected item based on previous purchases' with per-order supplier, cost price, and stock level at purchase. Shortfall: no alerting - nothing notifies when a received price exceeds the prior or contracted price by a threshold (threshold alerts exist only in the legacy Stock rules, which cover on-hand quantity, not purchase price). https://k-series-support.lightspeedhq.com/hc/en-us/articles/11207355170203-Purchase-Reports · retrieved 2026-08-05
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 thresholds plus purchase-order generation. Forecast-driven suggested order quantities are not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407509542043-Stock-management-Inventory · retrieved 2026-08-01
Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.
inventory-waste-logging
'Use the Wastage feature to update stock levels when items are discarded or destroyed and keep track of waste reasons and the value of what was lost' - Stock management > Wastage provides a dashboard of waste events filterable by date and waste reason showing 'the reason and value behind what was lost', and creating a wastage event adjusts inventory. Waste cost is reported separately from count variance: Discrepancy reports carry distinct 'Wasted Qty/Value' columns alongside Variance, and POS-side wastage discounts surface as 'Loss' apart from comps in Business/Shift reports. https://k-series-support.lightspeedhq.com/hc/en-us/articles/7116014889499-Wastage · retrieved 2026-08-05
Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.
inventory-shelf-life-expiry
Re-sourced from the 812-character About Inventory overview, which promises nothing about completeness, onto the module's own navigation article. "Stock management gives you visibility and control over your products, ingredients, and purchased goods." and it then walks its sections one by one -- Items, Stock levels, Stock counts, Stock locations, Par levels, Wastage -- with no date-bearing feature and no expiring-soon report or alert among them. The per-item attributes are enumerated and carry no expiry field: "An overview of all items in inventory. Select specific items to link a supplier to that item or edit its measurement type." Counting is quantity-based -- "Stock counts help you perform inventory assessments by allowing you to enter the physical quantity on hand of each item." -- and the nearest thing to rotation is spatial, not temporal: "Create stock locations to help you and your staff identify where items are stored for stock counts (e.g., the bar, cellar, or walk-in fridge)." Reordering is threshold-driven, not date-driven: "Use par levels to establish item reorder points." The stated alternative for spoilage is after-the-fact loss capture: "Access wastage to monitor and track items that have been lost or discarded. From the Wastage dashboard, you can see the reason and value behind what was lost." and "Create new wastage events when items are scrapped to adjust your inventory and keep your stock levels up to date." The dedicated Wastage article (7116014889499) names expired ingredients as one waste reason among broken objects and staff error, with a free-text reason and notes -- a loss event recorded after spoilage, not a date tracked before it. Corpus check: use-by, best before, shelf life and shelf-life occur zero times across the 546 K-Series and 283 O-Series articles, and every expiration hit is a card, certificate, connection-code or voucher expiry. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407509542043-Stock-management-Inventory · retrieved 2026-09-05 adversarially verified
Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.
inventory-bar-partial-bottle
Fractional-bottle stock is documented, but only as recipe-derived depletion. "Some stock levels are represented by a decimal." -- because "stock levels are measured in units (like bottles or boxes), while recipes use dimensional measurements (like milliliters or grams)" -- and "The Inventory Add-on uses a conversion calculation to reconcile this:" "Decrease in stock level = Quantity used in the recipe / Total capacity of one stock unit", worked through on a bottle: "If you have 4 bottles of olive oil, your stock level will be reduced to 3.94 once you create a batch (4.00 - 0.06)." The quantity column is live -- "The number of items in stock. This value automatically updates when items are sold, purchase orders are received, or when stock counts are completed." SHORTFALL, twofold. First, the decimals are theoretical, not counted: the counting workflow in article 4407510354715 Performing stock counts enters the physical quantity in whole units, with plus/minus buttons that adjust the value by one, and documents no decimal, fraction or weight entry; there is no scale or weight-capture integration anywhere in the K-Series or O-Series corpus. So an open bottle is depleted on paper by recipe but cannot be counted back, which is the pour-cost variance this claim exists to measure. Second, the whole capability is gated behind a separately purchased module: every procedure here begins "Log in to the Inventory module with your Lightspeed credentials.", and the article names the component "The Inventory Add-on". https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407517612699-Stock-levels · 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
Vendor-listed accounting connectors: QuickBooks, Xero, Restaurant365. Per-category GL mapping and period COGS export shape are not documented. https://www.lightspeedhq.com/pos/restaurant-k-series/integrations/ · retrieved 2026-08-01
Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator
inventory-native-not-partner
'The Inventory module added to Lightspeed Restaurant K Series' - first-party, with Stock, Produce and Purchase sections and native recipe management, not a contracted third product. Costing is present but shallow: recipes carry a Gross profit percentage field and a derived Suggested sell price. It is a paid add-on with advanced inventory at the $399 Premium tier, which raises cost but does not make it a partner product, and the claim's test is native versus bolt-on. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407517428891-About-Inventory · retrieved 2026-08-02 adversarially verified
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 mobile half is documented and genuinely live: Pulse shows 'Live gross revenue, % change compared to the previous period, and time of last update', plus orders, covers, voids, discounts, comps, order and cover averages, table turn time, refunds and sales per labour hour, with an All locations view. Shortfall: the browser half is not. The Back Office Dashboard article says only that it 'summarizes important business activity in easy-to-read graphs and charts' and states no refresh interval or latency, so 'within minutes of the sale' is unevidenced for the browser, which the claim requires alongside the mobile app. https://k-series-support.lightspeedhq.com/hc/en-us/articles/29496064755099-About-the-Lightspeed-Pulse-App · 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
API exposes daily financials, sales data, tax rates and payment methods, implying an EOD close. A single reconciling close-out document is not documented publicly. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-01
Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.
reporting-pmix-modifier-level
Item-level PMIX is documented: the Product Mix Report gives sales by accounting group, order profile, statistical category and product, with quantity sold, Sales (tax incl.), Sales (tax excl.), margin and cost columns, filterable by order profile, device, staff, shift or tag over a chosen period. Shortfalls: modifier-level rows are not documented - modifiers appear nowhere in the report's described output (combos show component items only on hover) - and no daypart filter is documented on this report; the separate Filtering Reports feature offers an Hourly interval but only for 'date ranges of 1 to 3 days' and 'only to European Lightspeed Restaurant customers'. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403156004763-Product-Mix-Report · retrieved 2026-08-03
Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.
reporting-comps-voids-audit
Reason-coded, permission-gated voids with per-employee reporting: 'Void reasons are used to explain a refund or void applied to an order... Only POS users with the appropriate permissions can refund or void receipts', Discounts and Corrections reports show 'an overview of which void reasons have been applied to refunds or voids' plus discount breakdowns, and Staff Performance attributes Voids/Comps/Discounts dollar values to each employee; Daily Digest 'illustrates which employees are using discounts, how frequently, and for how much.' Shortfall: no report ties an approving manager to each void/comp - attribution is to the transacting user only - and per-event timestamped audit lines exist only on individual receipts, not as an audit report. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657449-Understanding-void-reasons · retrieved 2026-08-05
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
Counted-vs-expected reconciliation at drawer, shift, and employee level: the Drawer report 'shows the cash drawer amount entered at the start of the sales period, payments taken during the shift, cash amount expected to be in the drawer, and the actual cash drawer amount entered when the sales period is closed'; Consolidated Shift Reports compute 'Overage: Dollar value based on the discrepancy between what should be in the cash drawer and what was counted when performing a cash count'; every user has a personal 'user bank' drawer counted at user-shift start/end (Managing cash drawer operations), and the Cash drawer report shows 'how they were counted, and where discrepancies may have happened.' https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050328874-About-POS-reports · retrieved 2026-08-05
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
Sales per labor hour from actual punches is native: Staff Performance reports 'Sales per hour: The average amount in sales per hour' with 'Hours worked... based on all staff clock-in and clock-out times on the POS', sliceable hourly/daily, by user and user group; Pulse shows live 'Sales per labour hour'. Shortfall: labor cost as a percentage of sales is unavailable - no wage rates exist in the product, so no dollar labor cost by hour, department, or employee can be reported (cost-based labor analytics require the 7shifts integration). https://k-series-support.lightspeedhq.com/hc/en-us/articles/40994945471515-Understanding-the-Staff-Performance-report · retrieved 2026-08-05
Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator
reporting-server-scorecards
Per-server metrics cover average check and more: per-employee Order average (gross/net), Cover average, Covers, Orders, Tips, Refunds, Discounts, Voids, Comps in the Staff Performance table; Advanced Insights Staff reports 'display your sales data by server... view your server's average sales by check or cover and compare a server's performance to an overall average.' Shortfalls: no items-per-check metric, no attachment rate for named categories, and tips are reported as dollars, not as a percentage of sales. https://k-series-support.lightspeedhq.com/hc/en-us/articles/40994945471515-Understanding-the-Staff-Performance-report · retrieved 2026-08-05
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
Revenue splits by channel exist: Product Mix reports break sales down 'by accounting groups, order profiles, statistical categories, and products' (order profiles map to dine-in/takeaway/delivery/Uber Eats/UEAT/Order Anywhere channels), the Online orders report isolates third-party order payments, and item margin (sales minus costs) is computed. Shortfall: no channel P&L net of marketplace commission - commission and marketplace fees are not captured (the Online orders report reconciles only order-amount differences), so margin by third-party channel net of fees is not reported. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403156004763-Product-Mix-Report · retrieved 2026-08-05
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
Scheduled email reports exist but only for a fixed menu of reports: Reports > Reporting automation offers 'Daily revenue, all locations' or 'Daily Settlements, all locations', 'At the end of the day or At the end of the week', with a comma-separated recipient list; Advanced Insights adds the fixed 5:30 AM Daily Digest per location, and Lightspeed Tasks sends daily/weekly checklist summary emails to chosen recipients. Shortfall: arbitrary Back Office reports cannot be scheduled - there is no schedule option on the general reports. https://k-series-support.lightspeedhq.com/hc/en-us/articles/12285092786203-Automated-reporting-with-Lightspeed-Payments · retrieved 2026-08-05
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
The reference is public and covers orders, payments, menu and labour data. Shortfall: credentials are not self-service. 'Access to the Lightspeed Restaurant K-Series APIs is reserved for Lightspeed partners and approved merchants' — partners register for the Developer Portal, merchants 'can request access by contacting their Account Managers,' and other developers 'can apply to become partners.' The docs are public; the API is not. https://api-portal.lsk.lightspeed.app/quick-start/intro · retrieved 2026-08-02 adversarially verified
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
Order and payment lifecycle webhooks exist alongside staff-shift, reservation and PMS events, managed via API with Bearer auth. Shortfall: the claim requires documented retry behaviour and payload signature verification, and the K-Series reference documents neither — no HMAC signing, no retry/backoff policy, no replayable event log, no published rate limits. Delivery is unguaranteed and payloads are unauthenticated. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-02 adversarially verified
API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator
reporting-api-not-upcharged
'Raw API access' appears under the Premium tier only on the vendor pricing page — absent from Starter ($69) and Essential ($189), present at $399. API access therefore carries a $330/month subscription delta from entry, per location, on top of partner approval. https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-02 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
The vendor pricing page tiers capability heavily: Advanced Insights, Lightspeed AI, Tempo, Tasks, multi-location management, advanced inventory management, 'Multiple revenue center support for hotels' and 'Raw API access' are all plan-gated line items, and launch/onboarding services are Enterprise-only. Shortfall: reporting and integration access are not tier-neutral. https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-01 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
CLAIM: 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. This is a documentation-existence claim, and Lightspeed's documentation enumerates its reporting windows and none of them reaches 24 months, so the claim is false rather than merely unresolved. SERIES: both. THE PUBLISHED WINDOWS, AND THEY ARE CEILINGS RATHER THAN SILENCE: nine Advanced Insights reports state verbatim 'By default, the report displays data for the last 28 days' - Most Popular, Repeat Customer Favorites, Net sales, Gross sales, Sales > Covers, Card sales, Time of day, Day of week and New vs. repeat - and EIGHT of those nine add an explicit hard ceiling, 'Optionally, click Custom to specify the time period using a calendar, but you cannot select a date range longer than three months' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/7338242320283-Most-Popular-Report; also Net sales, Gross sales, Sales > Covers, Card sales, Day of week, New vs. repeat and Repeat Customer Favorites). Time of day is stricter still: 'You cannot select a custom time period for this report.' The two longest published look-backs are 12 months, in Magic Menu Quadrant - 'an item's performance over the last 12 months' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/7339064083739-Magic-Menu-Quadrant) - and the Guest book Customer scorecard, 'a color grid of your customer's activity over the last 12 months'. STATED IN FAIRNESS: the Location Summary's period picker offers 'Last 12 months', 'Last year' and 'YTD (last year)', which implies prior-calendar-year data is queryable, but no retention term is attached to it anywhere. NOWHERE does Lightspeed state how far back Back Office transaction detail is retained. THE LEGAL SET: the Lightspeed Service Agreement (87,129 characters of stripped text) contains no retention period for merchant transaction data, and what it does say about data cuts against a guarantee - 'Customer agrees that following termination of Customer's account and/or use of the Product, Lightspeed may immediately deactivate Customer's account and delete Customer Content' (https://www.lightspeedhq.com/legal/lightspeed-service-agreement/). The Data Processing Agreement does have a retention clause, section 8 'Retention and deletion', but it is qualitative and about Personal Data - 'Lightspeed processes Personal Data for as long as it is reasonably needed to deliver the Services' - and the Privacy Policy repeats it; neither states a reporting window. BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. BOUND LIMIT, AND IT IS THE REASON TO TREAT THIS ROW AS FALSIFIABLE: two of the seven gated articles are reporting articles - Device Reports (EMEA and Australia) in K and Accessing the purchase report in O. Neither is a retention-policy page, and the held North American twin, Device Reports (NOAM) (https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403156093211-Device-Reports-NOAM), documents no window at all, saying only 'Use the drop-down menu and calendar icon to change the report's time period'. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. In particular `retention` tokenises to 17 hits in 6 K docs and 1 in 1 O doc and NOT ONE is a reporting window: it is GUEST-retention analytics (the Magic Menu Quadrant's quadrants are defined by 'retention rate'), plus a Spanish fiscal clause and a SevenRooms partner blurb. `retain` tokenises 0 in K and 3 in O, all legal boilerplate; `archive` tokenises 29 in 10 K docs and 0 in O and is menu and item archiving, not report archiving, and no archive-retrieval fee is documented either. FALSIFIED BY: any Lightspeed page stating a retention period for Back Office transaction detail. https://k-series-support.lightspeedhq.com/hc/en-us/articles/7338242320283-Most-Popular-Report · retrieved 2026-09-15 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 exist only in the legacy Stock feature: a rule fires 'When the corresponding stock level goes below the specified quantity' for any stock/product and can 'Send an alert by email', 'Include an email report', or 'Invoke a HTTP end-point' (webhook) - but 'As of June 2023, the legacy Stock feature is no longer available to new customers.' No sales-metric alerting exists: Daily Digest is a fixed daily summary, Advanced Insights notifications cover Logbook mentions, and account emails cover 'certain sensitive actions', none operator-configurable on voids, discounts, or sales patterns. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4406100835227-Adding-rules · retrieved 2026-08-05
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
The Back Office Lightspeed AI agent 'pulls sales data from reports in the Back Office and presents it in an easy to read format, including charts and graphs', supports follow-up questions and custom instructions, and keeps chat history. Crucially it is gated on tenant data access: 'For users to ask questions about sales data, you will also need to enable the permission Sales report access' - a separate permission from general AI access, which is what distinguishes querying the operator's own data from a help-article bot. https://k-series-support.lightspeedhq.com/hc/en-us/articles/42676619412251-Understanding-the-Back-Office-Lightspeed-AI-agent · retrieved 2026-08-02 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
Guest-level analytics ship with Advanced Insights: Guest book auto-builds card-based guest profiles with All Time Spend, Average Spend, Visits, Last Visit and 'Estimated Lifetime Value'; rule-based lists segment by spend/visits; Campaigns reports 'the number of new vs. repeat customers'; the Customer scorecard shows per-guest history, favorite items and a 12-month activity grid; Repeat Customer Favorites and Benchmarks add retention views. Shortfalls: gated behind the Advanced Insights add-on (NA/AU/NZ, activated via account manager), and identity is payment-card based rather than loyalty/online-ordering records - cash guests are excluded. https://k-series-support.lightspeedhq.com/hc/en-us/articles/7340976689051-Guest-book · retrieved 2026-08-05
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
Forecasting is delivered by a partner fed with Lightspeed history, not by Lightspeed reporting: "Deputy is an all-in-one workforce management system which integrates with Lightspeed Restaurant to facilitate labor forecasting by sending real time data to Deputy and allowing you to accurately manage your staff based on busy and quiet periods." On enablement, "The backfill job is responsible for uploading your restaurant’s past 12 months of sales data into Deputy so that you can start seeing forecast trends." That is a stated alternative, not a bare absence: the sales history is exported so that the forecast can be computed elsewhere. Tenzo is documented the same way. No forward sales forecast at daypart or hourly granularity exists in the K-Series Back Office report set, which is historical and comparative only. https://k-series-support.lightspeedhq.com/hc/en-us/articles/19537081005467-Setting-up-the-Deputy-integration · retrieved 2026-09-05 adversarially verified
Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.
reporting-tip-tax-compliance
Declared-versus-charged per employee is documented: a clock-out declaration prompt ('Enter the amount of tips to declare... or tap Skip to proceed with zero'), earned tips in the employee's User report, manager breakdowns in the Labor and Business reports, and the article's note that declared tips 'will differ from their earned amount when they pay out tips to others or receive tips outside the POS app'. Shortfalls: tip pooling happens outside the system - staff are told to adjust their declaration for pool payouts, so no pool-distribution detail exists - and there is no tip tax-liability summary by jurisdiction; the article's only tax guidance is 'Speak with a tax professional to ensure you follow the correct rules... in your region.' https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities · 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 canonical multi-location guide enumerates the model exhaustively and it is two levels, not three: a business and its business locations. "Business locations are used when operating the same restaurant concept at different physical sites." The stated workaround for anything above that is separate tenants, not a group object: "If you oversee restaurants with different concepts, we recommend setting up a separate Lightspeed Restaurant business for each." Reporting scopes to one location or to all, with no intermediate tier: "Location reports aggregate data for a comprehensive overview of all locations". Permissions scope to a per-user list of locations, not to a group: "POS and Back Office users are shared across locations, but users only have access to the location they were created in by default", and to widen access "you can edit the business locations they are assigned to". The article's own three-way taxonomy — global, shared, local — is a data-sharing axis across a flat location set, not an org hierarchy. No region, group, district or brand object exists that reporting or permissions could be scoped to. https://k-series-support.lightspeedhq.com/hc/articles/23973504428059 · retrieved 2026-09-05 adversarially verified
Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.
multi-location-price-zones
'Price lists allow you to create preset pricing schemes to apply to menu items based on restaurant location and order profile.' One item record carries per-location pricing, and the order-profile link adds the channel and time axes over that same record - the article's own example links a Happy hour profile to a sixth price list. No item duplication is involved, which is the failure the claim exists to catch. https://k-series-support.lightspeedhq.com/hc/en-us/articles/4402274951323-About-price-lists · retrieved 2026-08-02 adversarially verified
Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.
multi-location-consolidated-reporting
A documented Location Reports family aggregates across locations: Consolidated Business Reports ('the financial information for the selected time period for all locations linked to your account'), Consolidated Product Reports, Consolidated Discounts Breakdown, Consolidated Shift Reports and Consolidated Fiscal Summary, exportable to spreadsheet or PDF. Shortfall: these are aggregations, not comparisons - no store-versus-store ranking and no variance flagging is documented, which is the half of the claim that makes above-store reporting actionable. https://k-series-support.lightspeedhq.com/hc/en-us/categories/8348673720987-Reports · 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
Liability reporting exists with multi-location filtering: the Gift cards statistics dashboard (Customers > Statistics) reports 'Outstanding balance: The total amount, including refills, currently loaded onto gift cards for the chosen location', with a Location filter that can 'Check the box beside each location', plus Loads and Redemptions activity; gift cards are managed business-wide under Customers > Gift cards and the gift-card payment method 'will be available in all locations.' Shortfalls: no article states a card sold at one location is redeemable at another, and no inter-store settlement/redemption reconciliation between owners is documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/43733543286683-Understanding-Gift-cards-statistics · retrieved 2026-08-05
A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.
multi-location-cross-location-loyalty
The customer record is shared: 'Customer profiles are consistent across locations, simplifying their management', and Back Office exposes Statistics, Transactions, Products and Loyalty cards per customer. Shortfalls, both explicit: the same article states 'invoices, amounts owed, and accounts receivable are managed separately at each location', and nothing documents whether a loyalty balance or stored order history is chain-wide or per location - the claim's operative test is a single balance across the brand, and that is unaddressed. https://k-series-support.lightspeedhq.com/hc/en-us/articles/23973504428059-Navigating-business-locations · retrieved 2026-08-02 adversarially verified
A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator
multi-location-multi-brand
Multi-concept operation on one account is positively steered away from: 'Business locations are used when operating the same restaurant concept at different physical sites. If you oversee restaurants with different concepts, we recommend setting up a separate Lightspeed Restaurant business for each.' A POS device belongs to one business location with one configuration; there is no mechanism for two brands with separate menus, receipts, and separately reportable revenue on the same terminal and drawer. https://k-series-support.lightspeedhq.com/hc/en-us/articles/23973504428059-Navigating-business-locations · retrieved 2026-08-05
Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.
multi-location-multi-tax-jurisdiction
Tax rates and accounting groups are per business location in the API, and Lightspeed ships Quebec WEB-SRM fiscal support — evidence of real jurisdictional handling. Inclusive/exclusive rules and exemption depth are not documented. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-01
Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.
multi-location-central-labor-policy
No labor-rule engine exists to centralize: K-Series labor is clock-in/out with PIN/QR, hours in Back Office, and tip declaration; there are no break, overtime, or predictive-scheduling settings at any level - 'overtime' and 'break enforcement' appear nowhere in the 527-article corpus - and nothing is enforced at the terminal. Scheduling and compliance are explicitly delegated to integrations (7shifts: 'the employee lifecycle, including hiring, training, scheduling, and paying'). https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050309174-Clocking-in-and-out · retrieved 2026-08-05
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
The vendor explicitly contemplates third-party purchase: 'If you choose to purchase your hardware elsewhere, we encourage you to purchase the supported models listed in this article.' The supported list is standard Apple retail hardware - iPad 7th gen and later, iPad mini 5th gen and later, iPad Air 3rd gen and later, iPad Pro, iPhone XS through iPhone 15 - buyable anywhere. The single exception is card terminals, which must be Lightspeed-certified because they ship with injected firmware. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-02 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
Minimum version stated exactly - 'The Lightspeed Restaurant (K Series) POS app requires a supported Apple device running iPadOS or iOS 18 or higher' - with device generations enumerated (iPad 7th gen+, iPad mini 5th gen+, iPad Air 3rd gen+, iPad Pro 11-inch 1st gen+ and 12.9-inch 3rd gen+, iPhone XS/XR through iPhone 15, iPhone SE 2nd and 3rd gen). Apple-only by design: no Android, Windows or Linux client is offered, which the claim treats as a named platform decision rather than a gap. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-02 adversarially verified
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
Supported hardware is a closed list ('Lightspeed only provides support for the hardware listed in this article'): POS devices are Apple iPads and iPhones only, and the Payment terminals table holds Mobile Tap, Verifone P400+, AMS1 Smart Terminal, Verifone V400m, S1F2 Smart Terminal with Printer, Verifone e285 and e280. The handheld ordering setup is 'Setting up Mobile Tap' (13189156370459): a Bluetooth card reader on an 'Adhesive metal plate' stuck to the back of an iPhone, or the 'Tableside Case for iPhone', 'a phone case designed to securely hold the Mobile Tap and your iPhone 12, 13, or 14'. No drop or IP rating is published for it. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-09-03 adversarially verified
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
The mobile payment terminals have user-removable batteries - the Verifone V400m and e285 SIM-replacement procedures document sliding off the battery cover and removing/reinstalling the battery in the field. Shortfall: the ordering handheld is a standard iPhone (iPhone XS/XR or later per Supported hardware) with a sealed battery, and Lightspeed publishes no rated full-shift battery life for any handheld; the Mobile Tap reader charges via USB/dock rather than swapping. https://k-series-support.lightspeedhq.com/hc/en-us/articles/18140638499355-Troubleshooting-Lightspeed-Payments-for-Restaurant-POS · retrieved 2026-08-05
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
The documented outage strategy is 4G on payment terminals, not handheld POS devices: 'Consider using payment terminals with 4G capability for standalone payments in case of outages by your ISP.' POS handhelds (iPhones/iPads) are documented exclusively on the dedicated store LAN - network requirements mandate Wi-Fi RSSI above -67 dBm on a dedicated router, and the only cellular reference for POS devices is using a mobile hotspot as a troubleshooting test. No cellular/LTE fallback for ordering handhelds is offered or documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/27536544139547-Network-optimization-checklist · retrieved 2026-08-05
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
The article documents both what keeps working (orders, table holds, multi-register sync, local kitchen and guest-check printing, cash/check/manual tenders, full menu access, clock in/out) and, in an 'Offline limitations' table, exactly what degrades: integrated Lightspeed Payments 'are not handled in real-time' and must use the terminal 'in standalone mode, with LTE/4G'; live reports and inventory do not update; new Back Office configuration is not visible; item pictures/descriptions/allergens are unavailable; 'gift card processing and K-series loyalty programs are unavailable'; accounting, delivery and online-order integrations are unavailable. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 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
First-party product with its own setup documentation, its own status-page component and a published price of $30/screen/month on all plans. KDS 2.0 documents named stations, per-station item routing, touch interaction and per-station Delayed/Late wait-time thresholds - the station-routing and fire-timing elements of the claim. It is not an integration-only dependency. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22168531609499-Setting-up-Kitchen-Display-System-2-0 · retrieved 2026-08-02 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
A first-party kiosk exists, but on a different SKU from this record's flagship. THE EVIDENCE IS O-SERIES: this article documents that "With Lightspeed Kiosk, customers can place their own orders, cutting down on lines at the counter.", that "The Lightspeed Kiosk O-Series app is compatible with our" supported iPad devices and that "all payments are processed through Lightspeed Payments", installed by "Tap the Search icon and search for Lightspeed Kiosk O-Series", activated per device in Back Office -- "Select how many kiosks you want to activate for the site. The total pricing will automatically update based on the number of kiosks selected." -- set up by "pairing it with an available Lightspeed Payments terminal", and driven by the POS's own catalogue: "The kiosk displays all products enabled for visibility in the Online products section." Hardware is bought, not bundled: "The required hardware can be purchased through your Lightspeed Account Manager or from our" webstore. THE K-SERIES SURFACE HAS NO FIRST-PARTY EQUIVALENT: the K-Series supported-hardware article (1260800124209) enumerates barcode scanners, receipt and label printers, network accessories, cash drawers, payment terminals, KDS and ODS and no kiosk, and the only K-Series kiosk path in the corpus is a partner one -- the UEAT integration article (36914000260891) defines a fixed order-profile code for a kiosk channel, UEATKI. O-Series partner lists add Foodhub, Tabin and TabSquare self-service kiosks. SHORTFALL, and the reason this is partial and not yes: the record's flagship is K-Series and an O-Series document may not carry a K-Series yes; the kiosk is a separately-priced per-device add-on rather than an included capability; only one form factor is documented (an iPad app -- nothing on countertop enclosures versus freestanding pedestals); and no accessibility or ADA compliance statement appears on either surface. https://o-series-support.lightspeedhq.com/hc/en-us/articles/45638355445275-Setting-up-Lightspeed-Kiosk · retrieved 2026-09-05 adversarially verified
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
The supported-hardware catalog is enumerated - Apple devices, barcode scanners, receipt and label printers, network accessories, physical cash drawers, payment terminals, Kitchen Display System, Order Display Screen (plus fiscal modules) - and includes no outdoor menu boards, order confirmation displays, or speaker/headset systems; no timer or speed-of-service measurement exists (KDS Statistics is per-item prep time). 'Drive-thru' appears nowhere in the 527-article help centre. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-05
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
Six receipt/kitchen printer manufacturers with connection types: SNBC (LAN), Blue Bamboo (Bluetooth), Epson (LAN/USB/Wi-Fi/Bluetooth), Seiko (LAN/Bluetooth), Bixolon (LAN/Wi-Fi) and Star Micronics (USB/LAN/Wi-Fi/Bluetooth). Both manufacturers the claim names as its test - Epson and Star - are present, and LAN/Ethernet kitchen printers are covered on four of the six. Not a vendor-branded-only list. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-02 adversarially verified
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
A named-model compatibility list is published: barcode scanners (Socket Mobile SocketScan S740 2D, CHS 7Ci, CHS 7Qi), cash drawers (Safescan LD 3336, APG Minota, Lightspeed Branded VPOS), receipt and label printers, certified payment terminals, and an Order Display Screen running on Apple TV 4th gen or newer over HDMI. Shortfall: no scales for by-weight items appear anywhere in the list, and multi-drawer-per-terminal is not addressed. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-02 adversarially verified
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
The published AOC documents the device posture: customers 'deploy P2PE POI terminals and PTS compliant magnetic stripe readers deployed at the customer premises', and 'Lightspeed K and L series support P2PE compliant devices and PTS compliant magnetic stripe readers'. The supported-hardware page reinforces the closed fleet - existing terminals cannot be used because they lack the certified firmware injection. Shortfall: the merchant's applicable SAQ type is stated nowhere in the AOC or the support documentation, and P2PE-compliant is not the same as a PCI SSC listed validated P2PE solution. https://pdf.lightspeedhq.com/documentation/PCI_AOC_R-C-X-K-L-O-G-Payments.pdf · retrieved 2026-08-02 · not refetchable · site policy · graded A when read adversarially verified
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
'With Tap to Pay on iPhone, Lightspeed Payments gives you the ability to accept payments directly on your iPhone with no additional hardware required... accept Apple Pay, contactless credit and debit cards, and other digital wallets through a quick tap on an iPhone.' Requirements: iPhone XR or above, iOS 18.4+, screen lock enabled, Lightspeed Payments, app 24.2+; activated under Payment > Payment methods > Lightspeed Payments > Tap to Pay for iPhone. https://k-series-support.lightspeedhq.com/hc/en-us/articles/10071706424347-Tap-to-Pay-on-iPhone-with-Lightspeed-Payments · retrieved 2026-08-05
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
Only KDS ($30/screen/month) is published on the vendor site. Terminal, reader, stand and printer prices are quote-only from Lightspeed; the $359–$519 reader figures are third-party. https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-01
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Hardware is purchased outright, from Lightspeed or elsewhere: 'You can purchase supported hardware directly from Lightspeed. Our online stores are customized for each region' (store.lightspeedhq.com and regional variants), and 'If you choose to buy your hardware elsewhere, we encourage you to purchase the supported models listed in this article' - merchants may even supply their own iPads/iPhones. No mandatory lease or subscription-bundled rental exists in the documentation. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-05
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
CLAIM: vendor documentation confirms WHETHER hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. PARTIAL: every ingredient of the answer is published and the conclusion itself is not. SERIES: the hardware documentation quoted is K-Series; O-Series documents the same commodity pattern, including supported iPads for the POS and for Lightspeed Kiosk. WHAT IS MET. First, the commercial relationship is settled in the Lightspeed Service Agreement's section 3, Hardware: '3.1. If Customer agrees to purchase point-of-sale equipment and supplies (Hardware), Customer shall pay the purchase price set forth in the Order Form or website' - an outright sale, with no lease, no title-retention clause, no obligation to return Hardware on termination and no reserved right to disable a device anywhere in the agreement (https://www.lightspeedhq.com/legal/lightspeed-service-agreement/). Second, section 3.2 excludes from the 30-day Limited Warranty any Hardware '(v) if used with products or services not provided or licensed by Lightspeed' - a clause that presupposes the customer MAY run the device with another vendor's products, and penalises it only by voiding a 30-day warranty, not by disabling the device. Third, the estate is commodity equipment Lightspeed invites the merchant to buy elsewhere: 'You can purchase supported hardware directly from Lightspeed... If you choose to buy your hardware elsewhere, we encourage you to purchase the supported models listed in this article' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware), the POS running on retail Apple devices - 'The Lightspeed Restaurant (K Series) POS app requires a supported Apple device running iPadOS or iOS 26 or higher' - with Epson, Bixolon, Star, Socket/Zebra, Zyxel and generic cash drawers as peripherals. The companion article draws a SUPPORT boundary, not a technical lock: 'Lightspeed commerce Inc. provides support for the hardware listed in the articles above. If your hardware isn't included in our list of supported hardware, we cannot guarantee compatibility' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/4402056687259-About-hardware). SHORTFALL 1: no Lightspeed document states whether a purchased device runs another vendor's software after cancellation. The O-Series cancellation guide walks the whole exit - 'Select Cancel site subscription... Under the Lightspeed Service Agreement, all plans require at least 30 days' notice prior to your next billing date, and cancelling before the end of a term may involve early termination fees or specific exit procedures' - and says nothing about the hardware you keep (https://o-series-support.lightspeedhq.com/hc/en-us/articles/31329343256603-Managing-your-Lightspeed-Restaurant-subscription). SHORTFALL 2, and it is a real exit cost the first pass missed: section 3.5 provides that 'any and all hardware including but not limited to tablet(s), printer(s) and/or payment terminal(s) that are being provided to the Customer at a discount (or free of charge) are conditional upon Customer using the point of sale services and Lightspeed Payments... for at least twenty-four (24) months from the date of such discount', and that a customer who stops within 24 months, or fails to average 100.00 in local currency of daily Lightspeed Payments volume, 'agrees to immediately pay Lightspeed the value of the hardware, plus shipping cos[ts]'. Discounted or free hardware therefore carries a repayment obligation on churn even though it is not locked. SHORTFALL 3: the payment half is unanswered - the Lightspeed Payments terminals are Lightspeed-certified and provisioned, and no document states whether a churned merchant can re-key one to another processor. BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is a hardware-lifecycle subject. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. Specifically `lock` tokenises to 22 hits in 15 K docs and 16 in 5 O docs against SUBSTRING counts of 295 and 388 - block, blocked, unlocked, clock, o'clock - and every tokenised hit is a cash-drawer lock, an iOS Guided Access lock, a screen lock or a user-permission lock; none is a device kill switch. `brick` reads 2 in K and 1 in O, none about hardware, and `churn` reads 0 in both. FALSIFIED BY: a Lightspeed statement that a purchased terminal can or cannot be re-used with another POS or processor after cancellation. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-09-15 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
Half the claim is met and half is affirmatively refused. A warranty term IS published: Section II.3.2, "Lightspeed warrants to Customer that new Hardware will be free from defects in workmanship and materials", "for thirty (30) days from the date that Hardware was shipped to Customer as original end-user". SHORTFALL: there is no replacement SLA and no turnaround figure of any kind. The remedy is discretionary and untimed — "During the Warranty Period, Lightspeed may, at its sole option, repair or replace Hardware without charge for either labor or parts" — and it is return-first rather than advance-exchange: "Charges for returning Hardware shall be for Customer" account, and "A restocking fee may also apply". After 30 days Lightspeed exits entirely: "Following expiration of the Warranty Period, Customer must contact manufacturer for any repairs or replacement". II.3.4 makes it exclusive — "REPAIR OR REPLACEMENT ARE THE EXCLUSIVE REMEDY PROVIDED IN CONNECTION WITH THE PURCHASE BY CUSTOMER OF THE HARDWARE" — and Section I.16 states "LIGHTSPEED EXPRESSLY DISCLAIMS ANY SPECIFIC SERVICE LEVEL WARRANTIES OR COMMITMENTS", glossed as "Our Products are sold without any service level warranties or commitments". https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-09-05 adversarially verified
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
Bring-your-own-Apple-device is the documented model: the POS app runs on any supported iPhone/iPad on iOS/iPadOS 18+, hardware may be bought 'elsewhere', and per-user security exists (PIN/QR login per POS user, Back Office permission groups; Tap to Pay requires a passcode/Touch ID/Face ID on the phone). Shortfall: nothing addresses staff-owned personal phones specifically - no MDM guidance, data-separation, or personal-device policy is documented, so the claim's 'documented permission and security model' for personal BYOD is only partly met. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-05
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
A device console exists for POS devices: Back Office POS > Devices shows each device's state ('Connected... In background... Disconnected'), sync status (Ok / Remote reload requested / Reload required), Application version, OS version, IP/SSID, with remote configuration reload from the Back Office plus disable, audit, and export; the KDS hub separately lists connected displays with Connected/Disconnected status and event-sync counters. Shortfalls: printers and payment terminals are not in this console, there is no remote reboot, and app updates come via the App Store with no staged rollout. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804658149-Managing-POS-devices · retrieved 2026-08-05
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
Documented first-party beverage-dispense hardware integration, but the flow is inverted relative to the claim's operative test. Lightspeed's K-Series help centre publishes a setup article for Dirmeier (refetched 2026-09-15, HTTP 200, every quote confirmed verbatim against raw bytes): "Dirmeier is an automated drink dispensing system. The integration between Dirmeier and Lightspeed Restaurant allows you to connect your POS and Dispenser, enabling items set up and ordered through the POS to generate credits in the Dirmeier dispenser." It is "a paid add-on", set up as a virtual production center ("From the navigation menu, select Hardware > Production centers", "Select from the Device for connection drop-down menu: Dirmeier", "Set the Destination IP address in the following format: http://{ip_address}/cash/1.0"), and requires that "item SKUs in Lightspeed must match the PLUs in the Dirmeier drink dispenser". The article enumerates exactly two modes, in one list introduced by "The integration supports two modes:": "Reporting Only: Tracks POS orders and compares them with items poured from Dirmeier" and "Restrict Pouring When Credits Are Available: Allows pouring only when items are ordered through the POS and the logged-in user matches them between systems." SHORTFALL: in both modes the POS order is the authoritative event and the dispenser consumes it - the POS grants pouring credits, it does not receive pours. A tokenised census of the entire article body returns check 0, tab 0, bill 0, receipt 0 and automatically 0, against dispenser 14, credits 3 and pouring 3, so nothing documents an unattended pour creating or appending a line on an open POS tab, which is what this claim asks. Dirmeier is also a dispense-control system rather than a guest-operated self-pour wall; the hardware types this claim literally enumerates are represented only at grade C, as vendor integration-directory tiles - US BeerSAVER Systems, "the No.1 draft beer flow metering system in hospitality", which states the same inverted direction ("We collect the sales data from your POS and display the information against what is being poured", "measure each pour against the sale amount"), and Kegtron, which "connects Lightspeed ePOS with real-time keg pour data. Every ounce poured is automatically compared to sales figures" - both partner-side poured-vs-sold variance reconciliation in the partner's own cloud, neither posting to a check. Their Compatibility labels are tag-split markup ("Lightspeed <strong>Restaurant POS (K-Series)</strong>") and so are not contiguous quotes; BeerSAVER lists U-, K- and L-Series, Kegtron K-Series only. BOUNDS AND POISON: the Zendesk help-centre search API is fuzzy-OR and its counts are worthless except at the extremes - "self-pour" returns 61 and "tap wall" 162, both stuffed with Tap to Pay and networking articles. Only its extremes are used here: query "pour" returns count 1, the Dirmeier article, making it the sole K-Series article that mentions pouring at all, while "PourMyBeer", "iPourIt", "Kegtron" and "BeerSAVER" each return count 0, so the two partner tiles carry no setup documentation. The 246-entry vendor integration directory names no self-pour tap-wall vendor (PourMyBeer, iPourIt and Table Tap all zero). A first-pass beverage vocabulary would have manufactured a clean absence here: the vendor's words are "drink dispensing", "credits" and "poured", never "self-pour". https://k-series-support.lightspeedhq.com/hc/en-us/articles/26397623938971-Setting-up-the-Dirmeier-integration · retrieved 2026-09-15 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
CLAIM: inbound caller ID hardware OR a telephony integration that pops the customer record and order history at the POS on an incoming call. PARTIAL: the integration exists and is vendor-named, but the pop is shallower than the rubric asks and the availability is narrow. WHAT IS MET, AND IN WHICH SERIES: O-SERIES ONLY. The O-Series help centre publishes Lightspeed's own partner roster - 'This guide lists the partners Lightspeed can be integrated and provides links to relevant support guides' - and names Voicee in its Marketing row (https://o-series-support.lightspeedhq.com/hc/en-us/articles/31329284546971-Lightspeed-Restaurant-supported-integrations), which lifts the evidence from a locale-partitioned marketing directory to a first-party support document. Lightspeed's own page for the partner describes it as 'Lightspeed Caller ID Cloud-Phone with Advanced Call Flow Features... You can now answer every call with any personalised greetings' and lists 'Find POS Orders - Find a pending order in your Lightspeed POS and alert your staff that they're calling about a particular order', under 'Compatibility: Lightspeed Restaurant POS (O-Series)' (https://www.lightspeedhq.com/au/integrations/voicee/, re-fetched 200 on 2026-09-15; that page files Voicee under 'Category: Features / Tools'). SHORTFALL 1 - SERIES AND MARKET: O-Series only on Lightspeed's own compatibility line, and O-Series is the Kounta Australia/New Zealand line, so this is not available in the record's primary market. SERIES AND MARKET, established by the verifier rather than assumed: O-Series is the Kounta lineage and is an Australia/New Zealand line. support.kounta.com 301s to o-series-support.lightspeedhq.com. The O-Series Payment Integrations section is Tyro, Windcave (NZ), Eftpos NZ/Verifone (NZ), Westpac Presto Smart and Smartpay, every one Australian or New Zealand; its Online Ordering partner row is 'Deliverect (Uber Eats, Menulog, Doordash), Bopple, Hey You, LOKE, Me&u, MOBI, Mr Yum, Order Up!, Ritual', likewise; and the string 'United States' occurs in 1 of the 281 O articles, in shared iPad-stand boilerplate. K-Series is the multi-region flagship, documented across the US, Canada, the UK, Europe, Australia and New Zealand. Voicee's contact number on the page is Australian. The K-Series flagship has nothing: across all 537 K articles tokenised `telephony` 0, `IVR` 0, and `caller` tokenises to ONE hit, anti-phishing advice - 'Scammers can use technology to alter the number they appear to be calling from, so that a legitimate business number shows up on your caller ID' (https://k-series-support.lightspeedhq.com/hc/en-us/articles/23340222300059-Following-security-best-practices-to-protect-your-business-online). SHORTFALL 2 - DEPTH: the rubric asks for the customer record AND order history to pop at the POS. What Lightspeed publishes is a lookup of a PENDING order plus a staff alert - not a customer profile with history - and no article describes an automatic screen pop. SHORTFALL 3 - NO FIRST-PARTY CALLER-ID PERIPHERAL: the K-Series Supported hardware article is a closed list, 'Lightspeed only provides support for the hardware listed in this article', covering iPads and iPhones, printers, cash drawers, scanners, payment terminals, KDS, order display, FDM and network modules, with no telephony device (https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware). BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is a telephony subject. PARTNER DIRECTORY CENSUS (450 unique slugs, union of the en-US, AU, UK, DE and CH integration sitemaps, 675 URLs). The verifier found the inherited fetch had a 14% hole: 65 of the 450 pages had returned HTTP 429 with no body, so controls had actually run over 385 pages while being reported as 450. All 66 were re-fetched at 200 and the census is now complete at 450/450, 227 of them restaurant-scoped. Over the complete 450: tokenised voice 0, IVR 0, telephony 0, caller 1 (Voicee), Apple Business Connect 0, Apple Maps 1, WCAG 0, VPAT 0, accessibility 0. Exactly two pages carry Category: Kiosk, both Compatibility: Lightspeed Restaurant POS (K-Series): INFI (https://www.lightspeedhq.com/integrations/infi/) and Kurve (https://www.lightspeedhq.com/uk/integrations/kurve/). BOUND LIMIT, disclosed: this public directory is not the whole partner manifest. The K-Series article About the Integration Hub describes a second, in-product directory - 'The Integration Hub is a directory of third-party integrations that work with Lightspeed Restaurant. With hundreds of integrations available...' - reached from the Back Office navigation bar and therefore behind a merchant login, and the O-Series supported-integrations article itself defers to it: 'Find the partners we integrate with by exploring the integration menu from your Lightspeed back office.' No zero over the public directory is a statement about the Hub's contents. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. `Voicee` itself tokenises to 3 hits in 1 O article and 0 in K, and is the only left-boundary stem hit that `voice` produces anywhere in the corpus. https://www.lightspeedhq.com/au/integrations/voicee/ · retrieved 2026-09-15 adversarially verified
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
The full K-Series API reference renders without login, NDA or sales contact, exposing named endpoint groups: Order and Pay, Financial and FinancialV2, Items, Rich Item, Staff (shifts, users, permissions, webhooks), Reservations for Platforms, PMS, Tax Breakdown and ID Cards. A developer can size an integration before purchase, which is what the claim tests. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-02 adversarially verified
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
'Raw API access' is a Premium-only line item on the vendor restaurant pricing page, so the merchant-side cost of integrating is a $330/month delta from Starter or $210/month from Essential, per location. Lightspeed publishes no separate partner fee, revenue share or per-location API charge on top of that. https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-02 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
A demo environment exists (auth.lsk-demo.app) but the portal states demo accounts are created by approved partners registered in the Developer Portal — not open to any developer. https://api-portal.lsk.lightspeed.app/quick-start/intro · retrieved 2026-08-01
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
OAuth 2.0 authorization-code grant is genuine, with space-delimited URL-encoded scopes and a merchant consent step. Shortfalls: only three scopes are published (financial-api, orders-api, offline_access), which is coarse rather than granular; scope allocation is gated on Lightspeed, not the operator - 'You will only be able to request the access scopes that your API client has been granted permission to request', and 'Merchants can contact their account manager to request additional scopes'; and no merchant-facing mechanism to revoke an individual app's grant is documented. https://api-portal.lsk.lightspeed.app/quick-start/authentication/authorization-overview · retrieved 2026-08-02 adversarially verified
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
Push exists and polling is not required: the reference publishes Order Notification, Payment Notification and Item Availability Notification callbacks, plus shift, reservation and PMS notification categories. Shortfall: the claim enumerates created, modified, paid, voided and refunded as the order lifecycle, and the reference exposes a single order notification and a single payment notification - no void event and no refund event is published, so an integrator cannot subscribe to the two states that matter most for reconciliation. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-02 adversarially verified
Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator
extensibility-webhook-reliability
The public K-Series OpenAPI spec (914 KB, 74 paths, host robots fully permissive) documents webhook delivery credentials rather than signatures: apeWebhookEndpoint has withBasicAuth/username/password, and the Reservations platform webhooks accept BASIC_AUTH, BEARER_TOKEN, API_KEYS or OAUTH2 client credentials that Lightspeed sends with each call (reservation-servicePlatformWebhookResponseDto.currentAuthType). 'signature' occurs only as cardholder signature data and 'HMAC' nowhere; 'retry' occurs only for PMS charge retries. Shortfall: no HMAC signing, no retry/backoff policy, no replayable event log. https://api-docs.lsk.lightspeed.app/source.json · retrieved 2026-09-03 adversarially verified
A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.
extensibility-order-injection-api
The Order and Pay group publishes 'Create Local Order' and 'Create To Go Order' write endpoints alongside check and payment operations, so an external system can originate both dine-in and takeaway tickets. Corroborated operationally by the Deliverect path, where externally-originated marketplace orders arrive as POS tickets in real time. The reference does not itself state that injected orders fire to KDS or printers. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-02 adversarially verified
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means when it says the roster is tracked in real time, and it is a CENSUS rather than a floor: every provider integrated with DoorDash appears in it with a tier, so a vendor that is absent altogether is not in the programme at any tier. This vendor appears nowhere in the 64 entries, under any provider id or friendly name — checked mechanically against both fields, with the only near-misses being substring coincidences (Speedline against Lightspeed, vroom_restaurant against Restaurant365) that were read and rejected. SUPERSEDES the 2026 announcement post most of this corpus cited: that post introduces its ten names with the word `include`, which makes it a floor and never a ceiling, and reading it as a ceiling is what produced this cell's prior grade. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11
Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator
extensibility-first-party-delivery-integrations
Uber Eats and Uber Direct are direct integrations. DoorDash and Grubhub run through Deliverect, resold as 'Lightspeed Delivery by Deliverect' — a paid middleware layer by another name. https://www.lightspeedhq.com/pos/restaurant-k-series/integrations/ · retrieved 2026-08-01
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
Deliverect confirmed as a supported endpoint. A second major aggregator (Chowly, Otter, Checkmate) is not confirmed in Lightspeed's own integration listing. https://k-series-support.lightspeedhq.com/hc/en-us/articles/25208938481691-Setting-up-the-Deliverect-integration · retrieved 2026-08-01
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
The Accounting category names QuickBooks, Xero, Restaurant365, DAVO Sales Tax, Tiphaus and Restaurant Accounting Services Inc, so QuickBooks plus a second GL is satisfied on the counting test. Shortfall: the claim's discriminator is 'mapped journal entries rather than CSV-only export', and the integrations page is a partner directory that describes no field mapping, no chart-of-accounts configuration and no journal structure for any of the six. Whether these post mapped journals or export files is unestablished. https://www.lightspeedhq.com/pos/restaurant-k-series/integrations/ · 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
Two or more named partners exist under Payroll on the vendor's integrations page (7shifts, Atlas, Planday, Push Operations, Restaurant Accounting Services Inc, Restaurant365), so the counting half of the claim is met. Shortfall: 'without manual re-keying' is unevidenced - no first-party documentation describes labour hours flowing to any of these partners, and the directory entry is a marketing listing rather than an integration guide. https://www.lightspeedhq.com/pos/restaurant-k-series/integrations/ · retrieved 2026-08-02 adversarially verified
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
'The Integration Hub is a directory of third-party integrations that work with Lightspeed Restaurant', browsable in Back Office with topic filters (Inventory, Marketing among them) and a documented self-service path - search a solution and follow its onboarding steps - describing hundreds of integrations. The public lightspeedhq.com integrations page carries the same directory with partners named by category for prospects who are not yet customers. https://k-series-support.lightspeedhq.com/hc/en-us/articles/40834565217691-About-the-Integration-Hub · retrieved 2026-08-02 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 K-Series API's Order and Pay group exposes the transaction engine to third-party UIs: 'Create Local Order' and 'Create To Go Order' POST endpoints inject orders, with operations to apply payments and manage open checks, plus Order and Pay webhooks for lifecycle events. This is how certified ordering fronts drive the POS in production (UEAT web/kiosk ordering posts orders via the external payment API; Deliverect injects marketplace orders). Access requires partner/approved-merchant API credentials via the developer portal. https://api-docs.lsk.lightspeed.app/ · retrieved 2026-08-05
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
Domain-by-domain machine-readable exports are self-serve: full customer list ('All data will export by default') with format choice; items, menus, and price lists import/export in bulk; per-customer transactions and invoices in PDF/CSV/XLSX; report tables export CSV/XLSX; German accounts get the mandated DSFinV-K full POS-data export; and the partner API serves Financials and receipts. Shortfall: no documented complete historical exit export - order/receipt history has no single bulk export, and no contract-end data-handover process is published (the Trust Center data-retention policy covers deletion, not handover). https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657189-Importing-or-exporting-customer-data · retrieved 2026-08-05
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
'Offline POS functionality': with the internet down but the LAN up, 'New orders can be taken, added to tables, and held as normal'; 'Production dockets (to kitchen or bar) and local guest checks can be printed, provided the POS device and local printers remain connected on the local area network'; 'The full menu, modifiers, discounts, and prices are available as they are stored locally on the device'; the active POS 'will log all activity and send its stored data once the internet connection is restored'. If the LAN also fails, only the active POS keeps taking orders and local printing stops. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 adversarially verified
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
Offline limitations table: 'Integrated payments (Lightspeed Payments) are not handled in real-time. The actual payment transaction must be handled using the terminal in standalone mode, with LTE/4G connection', and 'Payment terminals with a 4G (cellular phone network) backup will remain functional without internet or local connections'. Shortfall: this is a cellular-backed terminal fallback, not store-and-forward; a terminal without a cell connection 'will not function'. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 adversarially verified
The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator
reliability-offline-decline-liability
There is no store-and-forward card acceptance to carry liability: during an outage 'most basic order-taking functions will still work offline. But you'll still want to get back online quickly to use your hardware and process card payments' - card payments require connectivity (integrated terminals need the network; the documented outage fallback is 4G standalone payment terminals, which process online over cellular). With no offline card capture mode, no decline-liability policy exists or is needed, and none is published. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53288894613787-Troubleshooting-network-issues · retrieved 2026-08-05
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
'Multi-register sync: Orders opened on one POS will sync to other POS. Data will be stored locally, in the Active Device(s).' The connectivity model: 'If the connection with the internet is lost, devices can still communicate with each other on the local network'; 'Passive POS devices can still send data to active POS devices, but the active devices cannot forward the data to the cloud.' Only when the LAN itself fails does operation collapse to the single active POS. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 adversarially verified
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
Local continuity is documented but thin: 'If your network or internet service goes out, most basic order-taking functions will still work offline' (the App Store listing likewise advertises an offline mode), Quebec's WEB-SRM 'works in offline mode right out of the box. All transactions are stored locally on the POS', and the KDS 2.0 hub is a genuinely local server (a dedicated POS 'creates secure websites' serving station screens over LAN IP). Shortfall: no documented on-premise transaction engine or edge-server architecture for the ordering path - offline behavior is a one-line assurance with no described scope, sync, or multi-terminal consistency model. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53288894613787-Troubleshooting-network-issues · retrieved 2026-08-05
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
Internet down, LAN up: 'Printers remain functional as they connect via the local network' and 'KDS remains function[al]'; production dockets and guest checks print 'provided the POS device and local printers remain connected on the local area network (LAN/Wifi)'. Both stop if the LAN fails. https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality · retrieved 2026-09-03 adversarially verified
The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.
reliability-printer-fallback
Automatic failover is documented as an ordered printer list: 'When a device prints a receipt on a printing profile, it first tries to print on the first printer in the list. If this printer is turned off or cannot print, the device will attempt to print on the second printer in the list, and so on.' Shortfall: the claim's alert element is only half met - the sole documented signal is the optional 'Add a header when printing on a fallback printer' setting, which stamps _BACKUP PRINTER_ on rerouted tickets; no POS or KDS notification that a printer has failed is documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804607010-Managing-printing-profiles · retrieved 2026-08-03
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
The vendor does document partition behaviour, but as an architecture that avoids divergence rather than as a conflict-resolution rule. Documented: with the LAN up and the internet down, "Orders opened on one POS will sync to other POS. Data will be stored locally, in the Active Device(s)", and "the active POS will log all activity and send its stored data once the internet connection is restored". With the LAN also down, concurrent editing is foreclosed by design — "only the active POS can take orders and payments and connections to other POS devices or other local peripherals are lost", and "No communication between any devices (passive or active) is possible". SHORTFALL: the article never states what happens when two devices do produce divergent edits. No last-write-wins, no merge, no operator prompt is named anywhere in it, and the single-active-device model is described operationally rather than as a stated conflict policy. That is why this is partial and not yes. https://k-series-support.lightspeedhq.com/hc/articles/53028167251867 · retrieved 2026-09-05 adversarially verified
The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).
reliability-offline-feature-matrix
No offline-capability matrix exists in the K-Series help centre. The closest vendor artefact is 'Networking for Lightspeed Restaurant', which specifies mandatory outbound connectivity to *.lightspeed.app, *.ikentoo.com and *.adyen.com and 20 Mbps per POS device and payment terminal, and describes no degraded mode. An operator cannot find out from Lightspeed which functions survive an outage. https://k-series-support.lightspeedhq.com/hc/en-us/articles/16154347413275-Network-requirements-for-Lightspeed-Restaurant · retrieved 2026-08-02 adversarially verified
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
Sixteen per-component states for K-Series with no login - POS, Back Office, Back Office - Reporting, API (incl. Online Orders), Order Anywhere, Payments, Lightspeed Payments, Advanced Insights, Inventory, Pulse, Reservations, Tasks, Tempo, Benchmarks & Trends, KDS and AI Assistant - each carrying a 90-day uptime history, so an operator can separate a vendor incident from a local fault during service. https://status.lightspeedhq.com/ · retrieved 2026-08-02 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 K-Series support documentation publishes the channel and hours matrix. English phone support: 'Every day, 24 hours per day', with numbers listed by region (+1 833-573-7437 North America, +44 20 3695 9599 UK). Chat: 'We're available 24 hours a day, 7 days a week in all languages.' Non-English phone lines are limited (French 08:00-24:00 CET, German 08:00-23:00 CET, Dutch Mon-Fri 09:00-17:00 CET). No tier gate is stated - support is not presented as a premium add-on. https://k-series-support.lightspeedhq.com/hc/en-us/articles/360056758213-Contact-us · retrieved 2026-08-02 adversarially verified
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
Lightspeed dispatches its own installers: the site-preparation guide constrains what they will do on site - 'Lightspeed-contracted technicians cannot drill into or mount hardware on tile, concrete, stainless steel, marble, or granite. If needed, have a licensed contractor handle this work beforehand' - and instructs the merchant to 'Schedule your Lightspeed Restaurant hardware installation during a time when there is no active construction and your business is not open', to complete space modifications 'before your install date', and to 'Gather all necessary hardware and cables in a central location within your business prior to your installation'. Shortfall: the in-person service covers hardware installation only. Go-live itself is remote - the multilocation offering advertises 'hardware validation sessions prior to Go-Live accompanied with remote Go-Live support' and 'one-on-one, tailored onboarding' delivered remotely - and the hardware guide still allows the self-install path ('You may have hired an on-site professional to set up your hardware, or you might be doing it yourself'), so on-site attendance is not universal and no certified reseller/dealer network is published. https://k-series-support.lightspeedhq.com/hc/en-us/articles/10275376724507-Preparing-your-site-for-installation · retrieved 2026-08-06
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
Positive evidence of absence, not a zero-hit. Section I.16 disclaims the category outright: "LIGHTSPEED EXPRESSLY DISCLAIMS ANY SPECIFIC SERVICE LEVEL WARRANTIES OR COMMITMENTS", restated in the plain-language column as "Our Products are sold without any service level warranties or commitments". The hardware remedy that does exist is neither advance-exchange nor timed: Section II.3.2 gives a 30-day window in which "Lightspeed may, at its sole option, repair or replace Hardware without charge for either labor or parts", requires the unit be sent back — "Hardware must be returned in good condition in the original packaging and include all related components", "Charges for returning Hardware shall be for Customer" account, "A restocking fee may also apply" — and then ends: "Following expiration of the Warranty Period, Customer must contact manufacturer for any repairs or replacement". II.3.4: "REPAIR OR REPLACEMENT ARE THE EXCLUSIVE REMEDY PROVIDED IN CONNECTION WITH THE PURCHASE BY CUSTOMER OF THE HARDWARE". No included or purchasable replacement program with a stated turnaround exists in the contract that governs Hardware purchases. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-09-05 adversarially verified
The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.
reliability-pci-dss-4-attestation
Lightspeed publishes an AOC covering R/C/X/K/L/O/G and Payments, asserting Level 1 service-provider compliance, assessed onsite by ControlCase. Shortfall, and it is decisive for this claim: the published attestation is 'PCI DSS v3.2.1 Attestation of Compliance for Onsite Assessments - Service Providers', 'based on results noted in the ROC dated (January 11, 2024)' and signed February 2024. It therefore cannot cover the v4.x future-dated requirements that became enforceable on 31 March 2025. No v4.0/4.0.1 attestation covering the restaurant product was retrievable. https://pdf.lightspeedhq.com/documentation/PCI_AOC_R-C-X-K-L-O-G-Payments.pdf · retrieved 2026-08-02 · not refetchable · site policy · graded A when read adversarially verified
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Both halves are now documented, and one fails. Role-based access is strong: POS user groups ship as Floor staff, Manager, Trainee and Shift tracker with granular per-group permissions (order refunds, partial refunds, item price, table access, order split, tipping, time clock access, shift management). MFA exists for merchant Back Office logins via TOTP authenticator apps. Shortfall: it cannot be required. The article states 'Each user will need to enable MFA for their account. MFA cannot be enabled by location or by business' - so MFA is per-user opt-in and an administrator cannot enforce it, which is precisely what the claim's word 'enforceable' asks for. https://k-series-support.lightspeedhq.com/hc/en-us/articles/43642296058139-Setting-up-multi-factor-authentication · retrieved 2026-08-02 adversarially verified
A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.
reliability-self-serve-training
Extensive public help center including a 'Launching Lightspeed Restaurant checklist'. A terminal training/practice mode is not documented, and reviewers describe onboarding as self-teaching. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260805671909-Launching-Lightspeed-Restaurant-checklist · retrieved 2026-08-01
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
The one server-role device in the architecture cannot fail over: KDS 2.0 requires 'a dedicated POS to be the hub' and 'The POS assigned to be the hub for the KDS must always remain on for the system to function. Please keep it charged or plugged in at all times'; if the hub disconnects, screens stall ('If a screen drops offline, its sync count will stall until the connection is restored') and recovery is manual reconnection. No article documents another terminal automatically assuming the hub role; the ordering path itself is cloud-per-device with no promotable master. https://k-series-support.lightspeedhq.com/hc/en-us/articles/22168531609499-Setting-up-Kitchen-Display-System-2-0 · retrieved 2026-08-05
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
Documented for payment continuity only: 'Consider using payment terminals with 4G capability for standalone payments in case of outages by your ISP' - the Verifone terminals carry SIM cards (Settings > Network > Cellular per the troubleshooting guide), so card acceptance can continue standalone over cellular. Shortfalls: this is not automatic failover of the POS - ordering devices have no documented cellular fallback (a mobile hotspot appears only as a troubleshooting test), and standalone-mode payments are decoupled from the POS check. https://k-series-support.lightspeedhq.com/hc/en-us/articles/27536544139547-Network-optimization-checklist · retrieved 2026-08-05
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
Pricing is quoted per month on the public page, but the Service Agreement is built around an Initial Term with automatic renewal and a 90-day notice window; third parties report 1–3 year terms as standard. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-08-01
Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator
commercial-no-early-termination-fee
The published Service Agreement provides that early customer termination incurs non-recurring fees owed, the remaining recurring fees for the term, and the difference between list and discounted pricing, and that 'all payments by Customer to Lightspeed under this Agreement are non-refundable.' An ETF exists; Lightspeed publishes no dollar figure. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-08-01 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
Section 4.2 of the public Service Agreement: 'Upon expiration of the Initial Term and unless otherwise stated in the Order Form or herein, this Agreement will automatically renew for a duration equal to the Initial Term', terminable on 'written notice to the other party at least (i) where the Current Term is more than ninety (90) days, ninety (90) days prior to the end of the Current Term; or (ii) where the Current Term is less than ninety (90) days, such period of notice equal to the Current Term'. Both the renewal mechanic and the notice window are diligenceable before signing; the Initial Term length itself is quote-specific. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-08-02 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
The software can be operated with a third-party processor -- Lightspeed documents and supports five of them -- but the agreement mandates against it and prices the alternative. The mandate is general, in Section I: "Customer must use Lightspeed Payments unless otherwise agreed to by Lightspeed in writing", conditioned only on the customer using the Products, being eligible, and being "is located in a jurisdiction in which Lightspeed Payments is offered". Section I.5.1 confirms the penalty is a Fee under this Agreement: "Fees shall include, but are not limited to, applicable fees relating to Customer" use of a payment provider other than Lightspeed Payments. Section I.5.4 sets it: a customer who "processes transactions through a payment processing service other than Lightspeed Payments" is one from whom "Customer will be charged a monthly Fee for each month in which Customer processes transactions through such service", sized "in accordance with Fee table linked here". CORRECTION TO A WIDELY REPEATED FIGURE: the $/EUR/CHF 99.00 flat monthly gateway fee is NOT the general or the K-Series number. It sits at Section II.2.2, inside the product-specific item headed "Lightspeed Restaurant POS (U-Series)" and immediately after that item's Meraki router licensing clause, and reads "99.00 per month for each month in which Customer processes a transaction through such Third-Party Services provider". U-Series is a fourth SKU letter, not the K-Series flagship, so the $99 may not be cited against this record; the K-Series penalty is the I.5.4 volume-tiered table, whose tiers could not be retrieved because they route to regional PDFs on pdf.lightspeedhq.com, whose robots.txt disallows all agents. SHORTFALL: a contractual requirement to use in-house processing wherever it is offered, plus an uncosted monthly penalty, sitting on top of a genuinely documented third-party path (K-Series article 1260800124209 enumerates supported terminals for CCV, SIX/Worldline, SumUp, PayPal and Verifone; article 1260804605710 treats third-party processors as a first-class payment type). Card rates themselves are out of scope of this document: "Lightspeed Payments is a separate payment processing service governed by a different set of agreements", which Lightspeed does not publish. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-09-05 adversarially verified
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
Nothing interchange-plus is published for Lightspeed Restaurant. The Restaurant payments page defers rates to the pricing page - 'View our competitive processing rates on our pricing page' - and the Restaurant pricing page then publishes no processing rate at all: no percentage, no bps markup, no per-transaction cents figure, and the word interchange appears nowhere. Payment processing is listed only as a plan feature ('Integrated payments'). The sole published rate path is a bespoke one: 'Processing over $50K? Your current processor may be overcharging you... Contact our experts today for a customized quote.' A claim about what the vendor publishes is directly checkable, and the published answer is nothing, so a stated interchange-plus option with a specific markup does not exist. Note: the previous citation (lightspeedhq.com/payments/) now redirects to the Lightspeed RETAIL payments page and its blended-rate quotation is not carried here. https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-09 adversarially verified
The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator
commercial-rate-increase-clause
The published agreement grants the opposite of a cap and forecloses penalty-free exit. Section I.5.2: "Customer is obligated to pay all of the Fees due under the renewed contract at the then-current prices for the duration of the Renewal Term", and "any discounts offered under the initial Order Form shall not carry over or pertain to the Renewal Term". No cap, no notice period, no rate-change-triggered exit right. Exit is affirmatively penalised: Section I.4.2, "Except as otherwise specified herein, Customer may not terminate this Agreement prior to the expiration of the Term", and Section I.13.5, under which "Customer will be charged an early termination fee" summing unpaid non-recurring Fees, all recurring Fees for the remainder of the Current Term, and clawed-back software and Hardware discounts. Scope stated plainly: card-processing rates themselves sit under a separate contract — Section II.4 says "Lightspeed Payments is a separate payment processing service governed by a different set of agreements", referenced only in the Order Form and merchant application, which Lightspeed does not publish. The finding is over the agreement Lightspeed does publish, and it contains no cap and no penalty-free exit. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-09-05 adversarially verified
Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).
commercial-pricing-published
Per-location software tiers published ($69/$189/$399 + Enterprise quote) and KDS at $30/screen/month. Additional register/terminal pricing is NOT on the vendor page (the $59/month figure is third-party). https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-01
Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator
commercial-module-unbundling
Online ordering, Contactless ordering, Reservations, Tasks and KDS are separately priced add-ons on Starter, but independent cancellation without repricing the base subscription is not documented. https://www.lightspeedhq.com/pos/restaurant/pricing/ · retrieved 2026-08-01
All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.
commercial-hardware-purchase-outright
Section II.3 Hardware knows only purchase; the words lease and rental appear nowhere in the agreement. II.3.1: "Customer shall pay the purchase price set forth in the Order Form or website (as applicable)". Title behaves like a sale — II.3.2 provides that "Following expiration of the Warranty Period, Customer must contact manufacturer for any repairs or replacement". The website price is real and public: Lightspeed's US store at store.lightspeedhq.com publishes a 70-URL sitemap of terminals, printers, cash drawers, scanners, stands, iPads and cables at outright USD prices with a cart, and offers no lease or rental tier. KDS requires no purchased screen — the K-Series KDS runs on a tablet or any screen with a browser. The one multi-year hook is conditional, not mandatory: II.3.5 applies only to hardware "being provided to the Customer at a discount (or free of charge)", which is "conditional upon Customer using the point of sale services and Lightspeed Payments, to the extent applicable, for at least twenty-four (24) months", failing which "Customer agrees to immediately pay Lightspeed the value of the hardware, plus shipping costs". A merchant paying list price incurs none of that. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-09-05 adversarially verified
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
The supported-hardware article documents standard off-the-shelf devices throughout, not vendor-only ones. The POS 'requires a supported Apple device running iPadOS or iOS 18 or higher' - ordinary consumer iPad 7th gen and later, iPad mini 5th gen and later, iPad Air, iPad Pro, iPhone SE/XS through 15 - with Back Office in Chrome, Safari or Firefox. Receipt printers are third-party ESC/POS models with per-model setup guides: Epson TM-T88V(VI), TM-T20II/III, TM-T82 III, TM-T70, TM-m30 series, TM-m10, TM-P80, TM-L90/L100, TM-U220 series; Star Micronics TSP100/143 (I/III/IV), TSP650 BT series, TSP700, mC-Print3; plus Seiko RP-D10/RP-E10/MP-B20, Bixolon SRP-275III and SPP-R300, and Zebra ZD410 labels. Cash drawers are Safescan LD 3336 (EMEA) and APG Minota (NOAM) on RJ12; barcode scanners are Socket Mobile. Purchasing from Lightspeed is offered, not required: 'If you choose to buy your hardware elsewhere, we encourage you to purchase the supported models listed in this article.' The real limit is scope of support, not lock-in - 'Lightspeed only provides support for the hardware listed in this article' - and separately the integrated payment terminals are a fixed certified list (Verifone P400+/V400m/e280/e285, AMS1 and S1F2 Smart Terminals, Mobile Tap), which is a payments constraint rather than a POS-hardware one. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware · retrieved 2026-08-09 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
Back Office supports report and stock exports, and the API exposes orders/payments/financials — but API credentials are partner- or account-manager-gated, and no complete self-serve transactional history export is documented. https://api-portal.lsk.lightspeed.app/quick-start/intro · retrieved 2026-08-01
Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator
commercial-export-customer-and-loyalty
Customer records export self-serve: Customers > Customer list > Export, 'All data will export by default, so deselect any information you wish to exclude', in Mac or PC file format. Loyalty card batches (VIP, punch) export to CSV from Back Office. Shortfall: no export of a points ledger (K-Series has no native points program) and no documented gift-card liability export; gift cards have a statistics page only. https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657189-Importing-or-exporting-customer-data · retrieved 2026-09-03 adversarially verified
Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator
commercial-post-termination-export-window
Affirmatively adverse rather than merely undocumented: the Service Agreement states that on termination 'Lightspeed may immediately deactivate Customer's account and delete Customer Content.' No grace window is reserved for the customer. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-08-01 adversarially verified
Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator
commercial-data-ownership-clause
Ownership is stated plainly in section 8.2: 'Customer retains all right, title, and interest in the Customer Content.' Shortfall: the same section grants the opposite of a constraint - 'a worldwide, royalty-free, sublicensable, transferable, and non-exclusive license to use, access, copy, reproduce, modify, create derivative works of, publish, communicate, transmit, translate, display, and/or otherwise exploit the Customer Content for the purpose of providing, operating, promoting, or improving the Products, including but not limited to creating benchmarking insights, market trend analysis, and recommendations using aggregate and de-identified Customer Content.' Sublicensable, transferable, and extending to promoting the Products, with the aggregate/de-identified language framed as a non-exhaustive example rather than a limit. https://www.lightspeedhq.com/legal/lightspeed-service-agreement/ · retrieved 2026-08-02 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
Tokenization is named in scope in the AOC - the assessed service is the 'Card Tokenization Service (CTS)' alongside the Cloud Point of Sale Application - and K series is documented as supporting P2PE compliant devices. Shortfall: the claim requires the vendor to name the resulting merchant SAQ, and no SAQ type appears anywhere in the attestation; the document is v3.2.1 (ROC January 11, 2024), and no PCI SSC validated P2PE solution listing is cited. https://pdf.lightspeedhq.com/documentation/PCI_AOC_R-C-X-K-L-O-G-Payments.pdf · retrieved 2026-08-02 · not refetchable · site policy · graded A when read adversarially verified
Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.
commercial-pci-dss-4-controls
Back Office MFA is documented: a TOTP second factor via Google/Microsoft Authenticator or OneLogin Protect, enabled per user under My account > Configure MFA; the January 2026 release notes introduce it. Shortfalls: 'Each user will need to enable MFA for their account. MFA cannot be enabled by location or by business', so it is optional rather than enforced for all cardholder-environment access, POS logins are PIN-based, and no payment-page script-integrity (Req 6.4.3/11.6.1) statement exists in the help centre or the trust-centre article (54212034872475). https://k-series-support.lightspeedhq.com/hc/en-us/articles/43642296058139-Setting-up-multi-factor-authentication · retrieved 2026-09-03 adversarially verified
Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.
commercial-privacy-dsar-tooling
A DPA is published and per-guest primitives exist: the Trust Center holds the 'Data processing agreement', 'Data retention policy', and a 'Data privacy request option'; in-app, operators can locate a customer, export their data (field-selectable customer-list export; per-customer transaction export in PDF/CSV/XLSX) and 'make changes to or delete customers', while Order Anywhere guests can self-delete accounts. Shortfalls: no DSAR-framed workflow names CCPA/GDPR request handling for guests, and deletion propagation to Guest book, card batches, or partner marketing records is not documented. https://k-series-support.lightspeedhq.com/hc/en-us/articles/23340222300059-About-data-privacy-and-security · retrieved 2026-08-05
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
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. NO, on both conjuncts, in both series. WHAT THE VENDOR PUBLISHES ABOUT COMPLIANCE, AND AN EXPLICIT CORRECTION: the K-Series article on Lightspeed's compliance reporting walks the Security Trust Center Resources tab - 'PCI and SOC 3 compliance reports (access requests not required)' and 'Redacted information security policies, SOC 2 Type 2 compliance reports, penetration testing attestations, PCI Roles and Responsibilities Matrix (access requests required)', then PCI AoC, SOC 3, SOC 2 Type 2 and SOC 2 Bridge Letter in their own sections (https://k-series-support.lightspeedhq.com/hc/en-us/articles/54212034872475-Accessing-Lightspeed-s-security-compliance-reports). No VPAT, ACR or accessibility attestation is among them. THAT LIST IS NOT A CLOSED ENUMERATION and must not be cited as one: the article's own scope line is 'This article provides an overview of Lightspeed's compliance reports across Retail, Hospitality, and Golf product Series', the list is introduced by 'You can click the tabs at the top of the Security Trust Center for more information on:', and the article states 'Some documents within the Resources section are access-restricted and not publicly viewable or downloadable'. The Trust Center itself is NOT bounded either: trust.lightspeedhq.com is a Vanta single-page application and every path on it, including a deliberately nonsensical control path, returns the same 6,766-byte shell with 23 characters of stripped text, so nothing here asserts what is inside its Resources tab. WHAT CARRIES THE VERDICT INSTEAD. First, the published Legal library at https://www.lightspeedhq.com/legal/ is a closed list of fourteen documents - digital marketing services terms, AI terms, service agreement, cookie statement, DPA, privacy policy, subprocessors, acceptable use, IP infringement, surcharging policy, Google user data, trademark and copyright guidelines, modern slavery statement, sustainability committee charter - and no accessibility document is among them. https://www.lightspeedhq.com/accessibility/ 404s, and https://www.lightspeedhq.com/legal/accessibility/ returns 200 but is a page-builder shell: 4,015 characters of stripped text consisting entirely of site navigation and footer, against 4,099 for the site's 404 page, with no body content whatsoever, so it publishes nothing. Second, no accessibility clause exists in the Lightspeed Service Agreement, the Data Processing Agreement or the Privacy Policy (WCAG 0, accessibility 0 in all three). Third, the second conjunct fails affirmatively: the O-Series kiosk setup guide enumerates the kiosk's entire configurable surface as an inactivity timeout of 20 to 90 seconds, a logo, a banner image or video, a welcome message and free-text Additional information - no audio mode, no tactile navigation, no screen-reader statement (https://o-series-support.lightspeedhq.com/hc/en-us/articles/45638355445275-Setting-up-Lightspeed-Kiosk). Fourth, the one first-party kiosk product page, https://www.lightspeedhq.com/au/pos/restaurant/kiosk/, contains zero occurrences of accessib, WCAG or ADA. BOUND CORPUS (re-derived by the verifier, not inherited): the K-Series help centre, 537 articles, and the O-Series help centre, 281 articles, 818 in all, 7,191,707 raw body bytes on disk. Both are complete censuses of the publisher's own manifest, not samples: the Zendesk Help Center API reports count=537 for k-series-support.lightspeedhq.com and count=281 for o-series-support.lightspeedhq.com, exactly matching what is held. Freshness re-measured for a bulk re-save and it is genuine: the largest single-minute updated_at bucket is 19 of 537 in K and 14 of 281 in O, with timestamps spread from 2024 to 2026-09. HREF FIXPOINT, re-run by the verifier and corrected: parsing every article body for /articles/<id> references and filtering to each series' OWN host gives 32 referenced-but-unheld ids in K and 18 in O. Probed one by one through /api/v2/help_center/en-us/articles/<id>.json, which discriminates three ways, K returned 30x404 and 2x401 and O returned 13x404 and 5x401, with ZERO unlisted 200s in either series; the fabricated control id 999999999999 returned 404 on both hosts and a known held id returned 200 on both, so the instrument works. THE GATED SET IS SEVEN ARTICLES, NOT FIVE. K: Editing and deleting Accounting groups (1260804605370) and Device Reports (EMEA and Australia) (28597447394715). O: Welcome to Lightspeed Marketing and Loyalty powered by Marsello (31329298256667), Managing your companies, sites and registers (31329437648923), Accessing the purchase report (31329487982875), Applying discounts or surcharges on the POS (31329342620699), How to hold an order with Lightspeed (31329465555739). A prior count of five missed the two reporting articles. Also corrected: 148 further article ids referenced from O bodies live on foreign hosts, 140 of them on support.kounta.com; support.kounta.com 301s to o-series-support.lightspeedhq.com, where those legacy Kounta ids 404, so they are dead legacy links and not a corpus hole, but probing them against the o-series host and counting the 404s as O-Series absences inflates the fixpoint denominator and must not be done. None of the seven gated articles is an accessibility subject. POISON, reproduced by the verifier in an independent script written to disk (never inline in a shell, because the shell collapses \b to a backspace) with a passing positive control on every run: Lightspeed 3,761 hits / 479 docs in K and 1,905 / 239 in O, order 3,092 / 319 and 1,171 / 157. voice reads 465 (K) and 182 (O) as a SUBSTRING and ZERO tokenised in both, every one of those 647 hits being invoice, invoices or invoicing - this exact trap is on record for this vendor. ADA reads 172 (K) and 56 (O) as a substring and ZERO tokenised - Canada, Nevada, upgraded, loaded. accessibility tokenises to 6 hits in 6 K docs and 1 in 1 O doc and not one is a conformance statement. retention tokenises 17 in 6 K docs and 1 in 1 O doc and every one is GUEST-retention analytics or a Spanish fiscal clause. Every zero was run three ways - substring, both-boundary token, and left-boundary stem - over BOTH the tag-stripped text and the RAW bytes with HTML comments stripped FIRST, and only stem mode moved anything: voice as a stem reads 3 hits in 1 O doc, which is the partner name Voicee. NEW POISON FOUND BY THE VERIFIER IN THE PARTNER DIRECTORY: IVR scores 2 substring hits and ZERO tokenised, both inside FRENCH words on the Swiss locale pages - livraison and suivre; and Business Connect scores 1 substring hit and zero tokenised, inside 'get your business connected' on the ilglu page. The one Apple Maps hit in the whole directory is Shipday's driver-navigation blurb, 'no matter if it's Google Maps, Apple Maps, or Waze'. The severe one here: `ADA` as a SUBSTRING scores 172 in K and 56 in O and TOKENISES TO ZERO in both - Canada, Nevada, upgraded, loaded, Granada - so publishing the substring figure would have manufactured a false positive on this exact cell. `accessibility` tokenises to only 6 hits in 6 K docs and 1 in 1 O doc and every one is a homonym: Apple's iOS Settings > Accessibility menu used to enable Guided Access (twice), a POS button's accessibility visibility setting in Managing menus, the Spanish fiscal-record clause on 'integrity, traceability, inalterability, conservation, accessibility, and legibility of records', 'Some regions require a printed menu for accessibility and transparency' (twice, in Order Anywhere articles), and one networking marketing sentence. WCAG, VPAT and 'Section 508' are zero in substring, token and stem mode over both the stripped text and the raw bytes. FALSIFIED BY: a VPAT or ACR published on the Trust Center Resources tab or anywhere on lightspeedhq.com, or a kiosk article documenting an audio or tactile non-visual mode. https://k-series-support.lightspeedhq.com/hc/en-us/articles/54212034872475-Accessing-Lightspeed-s-security-compliance-reports · retrieved 2026-09-15 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
Automatic surcharging with the compliance mechanics the claim names: 'Automatic surcharging with Lightspeed Payments is only available in Australia, Canada, and the United States'; excluded transaction types include 'Debit and prepaid cards (US and Canada)' - the automatic exclusion the claim requires - plus card-not-present and DCC; the fee is 'a percentage of the total bill added as a separate line item', the docs require that 'clear signage must alert customers of the surcharge at the point of entry, the point of sale, and on every receipt', caps are enforced by rule (max 3% US / 2.4% CA, never above cost of acceptance), and advance card-brand notification duties are spelled out. (Surcharge model only - no separate cash/card dual-price display mode - and unavailable on Mobile Tap or in Quebec.) https://k-series-support.lightspeedhq.com/hc/en-us/articles/12625085075995-Surcharging-with-Lightspeed-Payments · retrieved 2026-08-05
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 93 values — 56 upheld, 28 downgraded, 9 upgraded. It separately resolved 181 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Pricing and identity
| Field | Verdict | What the verifier found |
|---|---|---|
| pricing.software | downgrade-to-partial | Tier prices verified — Starter $69, Essential $189, Premium $399, Enterprise quote, KDS $30/screen/month. But 'not available at the entry tier' materially understates the gate: raw API access sits under Premium alone, so it is absent from two of the three published tiers, not one. I also resolved the ambiguity the field flags around advanced inventory — the page places it on Essential and Premium and adds 'Also available on all plans as an add-on,' which means it is purchasable at Starter rather than tier-locked. Both should be stated rather than left as 'renders ambiguously'. source |
| api_posture.cost_to_integrate | downgrade-to-partial | The framing is right but the figure is left for the reader to compute and the tier is unnamed. Verified on the pricing page: the tier that includes raw API access is Premium and only Premium, so the merchant-side cost is a $330/month subscription delta from Starter or $210/month from Essential, per location, before any partner-approval step. State the number. source |
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| order-capture-bar-tab-preauth | yes / grade B, cites Creating-and-managing-bar-tabs; note itself concedes incremental re-auth and stale-tab auto-close are undocumented | downgrade-to-partial | I retrieved the bar-tabs article. It establishes one third of the claim: 'Pre-authorization guarantees payment of the pre-authorized amount, not necessarily the order total.' The claim also requires incremental re-authorization as the tab grows and auto-close of stale tabs at end of day. Neither is described — the article's only response to a tab exceeding its hold is a yellow card-status indicator, with no mechanism for raising the pre-auth, and end-of-day tab handling is not mentioned at all. The article also restricts the whole feature to 'accounts using Lightspeed Payments located in Australia, UK, and the US.' A differentiator yes cannot stand on one of three named sub-capabilities plus a processor-and-geography gate; the researcher wrote the shortfall into the note and scored yes anyway. source |
| reporting-webhooks | yes / grade B, cites api-docs.lsk.lightspeed.app | downgrade-to-partial | The claim text is not 'webhooks exist' — it is webhooks 'with documented retry behavior and payload signature verification.' I read the K-Series API reference directly: order and payment lifecycle webhooks are there and are CRUD-managed, but there is no retry/backoff policy and no HMAC or payload-signature verification documented anywhere in it. The record's own extensibility-webhook-reliability cell says exactly this and is scored unknown, so the dossier contradicts itself across two cells. Half the differentiator claim is unmet: partial, shortfall named as no signing and no delivery guarantee. source |
| extensibility-menu-write-api | yes / grade B, note 'plus menus, modifiers and discounts' | downgrade-to-partial | I went through the reference's menu surface myself. Items are genuinely writable — Create Item (POST) and Update Item by ID (PUT). Modifiers are not: the only modifier operation exposed is Get Modifiers (GET). There are no create or update endpoints for modifiers or modifier groups, and no standalone price-write endpoint. The claim requires items, modifiers AND prices to be writable; the researcher's note asserts modifier write capability the reference does not carry. Item CRUD only — partial. source |
| kitchen-order-modification-alerts | yes / grade B, cites Using-the-Kitchen-Display-System-2-0 | downgrade-to-partial | The quoted sentence is real — 'If an order sent to the KDS is modified from a POS device, its order ticket will blink with the new information until a user taps on it to confirm the update.' But the claim asks that the edit 'visually flag the added, changed, or removed items on the live ticket.' What the doc describes is a whole-ticket blink with acknowledgement, not per-line diff highlighting of what was added, changed or removed. On a ten-line ticket the cook is told something changed, not what. Differentiator weight, so the gap between ticket-level and item-level matters: partial, shortfall is no item-level change marking. source |
| menu-pricing-combos | yes / grade B, upgraded from unknown by the prior verification pass | downgrade-to-partial | I re-read the menus-and-items article. It says 'Combos allow you to group items together for a fixed price. Customers can choose from a preset group of items or a list of applicable items,' with a drink-and-sandwich example. That is fixed-price grouping with choice sets. The claim additionally requires that components 'can be swapped with a price delta' and that the system 'automatically detect and convert eligible a-la-carte items in the cart into the combo price.' Neither appears — no upcharge-on-swap model, no cart-side combo recognition. The prior pass upgraded this to yes on the first sentence and never tested the other two conditions. source |
| delivery-menu-push | yes / grade B, note already states 'Channel-specific markup handling is not documented' | downgrade-to-partial | The claim explicitly includes 'channel-specific price markups' and photos as part of what must publish from the POS master menu. The Deliverect setup article documents menu sync out to the marketplaces but says nothing about per-channel markup or image publication, which the researcher's own note concedes and then scores yes over. Same pattern as the webhooks cell: shortfall recorded, value not adjusted. Partial — sync yes, channel-specific pricing not established. source |
| payments-gift-cards | yes / grade B, cites About-gift-cards-2-0 | downgrade-to-partial | I fetched the Gift cards 2.0 overview. It confirms a first-party gift-card product (setup, printing, POS use, online sales, back-office management) — the existence half is sound. But the claim requires cards 'redeemable across every location in the group' with 'real-time balance tracking,' and the article addresses neither. Cross-location redemption is not mentioned anywhere in it; the record's own multi-location-cross-location-giftcard cell is scored unknown, which is the same finding reached independently. First-party stored value: yes. Group-wide redemption and real-time balance: not documented. Partial. source |
| guest-loyalty-stored-value-gift | yes / grade B, cites Selling-gift-cards-2-0-online | downgrade-to-partial | Same evidence, and this claim is worded harder than the payments one: balances must be 'tied to the same guest profile and redeemable across all locations of the brand.' Neither condition is documented. There is no first-party guest-profile product in the K-Series help centre at all — the Loyalty section contains only the Marsello and Toggle integrations, as the record's own guest-loyalty-accrual-models cell records — so there is no unified profile for a stored-value balance to attach to. Partial: stored value exists, guest-profile linkage and brand-wide redemption do not. source |
| hardware-peripherals | unknown / grade F, rationale 'Lightspeed publishes no peripheral compatibility matrix for K-Series in the public help centre' | resolve-to-partial | This resolves rather than demotes: the rationale is factually wrong and the matrix exists. The K-Series 'Supported hardware' article publishes named-model lists for barcode scanners (Socket Mobile SocketScan S740 2D, CHS 7Ci, CHS 7Qi), cash drawers (Safescan LD 3336, APG Minota, Lightspeed Branded VPOS), receipt and label printers, payment terminals and an Order Display Screen (Apple TV 4th gen or newer over HDMI). It stops short of the full claim: no scales for by-weight items appear anywhere in it, and multi-drawer-per-terminal is not addressed. Partial, with those two as the named shortfall. source |
| hardware-printer-compatibility | unknown / grade F, rationale 'no vendor compatibility list was located' | resolve-to-yes | The researcher missed a published vendor compatibility matrix. 'Supported hardware' enumerates receipt printers across six manufacturers — SNBC, Blue Bamboo, Epson, Seiko, Bixolon and Star Micronics — over LAN, USB, Wi-Fi and Bluetooth connections, plus label printers (Zebra ZD410 over LAN; Epson TM-L90 Plus listed as compatible but not supported). Multi-manufacturer, LAN-capable, not vendor-branded-only. That is the claim, met on vendor documentation. source |
| hardware-os-platforms | partial / grade B, cites the Apple App Store listing; 'no vendor spec page' | upgrade-to-yes | A vendor spec page does exist. 'Supported hardware' states the requirement as 'iPadOS or iOS 18 or higher' and enumerates the supported device generations (iPads 7th gen and later; iPhone 11 through 15 series). The claim asks that vendor documentation name the client operating systems supported and state minimum OS versions and device specs — all three are satisfied. That Android and Windows are unsupported is a scope fact about the product, not a documentation gap, so it does not hold the cell at partial. Repoint off the App Store listing. source |
| hardware-commodity-devices | yes / grade B, sourced to the Apple App Store listing | upheld | Upheld, but the evidence needed replacing — an app-store listing establishes that an iOS build exists, not that an operator may source the device themselves. The 'Supported hardware' article does: it lists the supported iPad and iPhone generations, recommends purchasing from regional Lightspeed stores but acknowledges third-party purchase of matching supported models, and limits only the support obligation ('Lightspeed only provides support for the hardware listed in this article'). The payment-terminal carve-out in the note is confirmed separately on the payments page: 'you cannot use any existing terminal hardware you might already have as these have not been injected with the certified firmware.' source |
| payments-pay-at-table | yes / grade D, cites the restaurant marketing landing page | upheld | Upheld on better evidence than the marketing page it was resting on. 'Supported hardware' names the mobile card terminals K-Series supports — Verifone e285/e280, Verifone V400m, Mobile Tap, AMS1 and S1F2 Smart Terminals — which are handheld EMV/NFC devices taken to the table, and the seat-level split-bill article documents check splitting at the point of payment. Grade moves D to B on this repoint. source |
| payments-emv-nfc | yes / grade D, cites the payments marketing page | upheld | Upheld and regraded. The vendor payments page is marketing, but 'Supported hardware' enumerates the certified terminal fleet (Verifone P400+, V400m, e285/e280, Mobile Tap, AMS1, S1F2) as the only permitted card-entry devices, which is product documentation for the same proposition. Note the claim's Apple Pay / Google Pay wording is not individually confirmed in that article — contactless is, the named wallets are not enumerated. source |
| kitchen-station-routing | yes / grade B, cites Managing-production-centers; upgraded this pass off a pricing line | upheld | I retrieved the KDS 2.0 setup article rather than the production-centers one. It documents creating named stations ('Click Create a new station', unique name, 25 characters) and routing items to them by menu category — 'you might want the Menu categories > Alcohol items to go to this station if it's for a bar area.' Configuration is operator-side in Back Office with no vendor involvement. The claim reads 'by item, category, order type, or revenue center' disjunctively, so category-level routing satisfies it. The re-score off the $30/screen price line was correct. source |
| kitchen-all-day-counts | yes / grade B, cites Using-the-Kitchen-Display-System-2-0; new this pass | upheld | Confirmed in the article I fetched: the Items list view groups items across tickets and each group shows 'Order status at the top, Total number of items in this status, List and quantity of items, Accompanying instructions for each item in the list.' Aggregated outstanding quantity per item across open tickets on the station is exactly the claim. Modifier-level aggregation is weaker than the claim's parenthetical — instructions are listed per item rather than rolled up — and there is no printable prep sheet outside the KDS, but the substantive test is met. source |
| kitchen-sla-alerts | yes / grade B, note says 'no vendor-published default minute values' were located | upheld | Upheld, and the researcher undersold their own evidence. The article publishes both configurable thresholds explicitly: 'Delayed After: This is the elapsed time after which KDS will flag a ticket as being delayed, in minutes. Delayed tickets will pulse with an orange glow' and 'Late after: ... Late tickets will pulse with a red glow.' That is configurable target time with two-step visual colour escalation, which is the claim. The real remaining gap is escalation off the screen — no manager-device alert and no speed-of-service report is documented, consistent with kitchen-speed-of-service-reporting staying unknown. source |
| kitchen-expo-consolidation | unknown / grade F | upheld | I tried to break this and could not. The KDS 2.0 usage article documents stations, an Items list and a Condensed view, but no expo or pass screen that consolidates one guest check across multiple prep stations and withholds completion until every contributing station has bumped. That gating behaviour is the whole claim and it is simply not described. Absence of documentation, so unknown rather than no. source |
| kitchen-recall-refire | unknown / grade F, rationale 'Returning a bumped ticket to an active state ... is not described' | upheld | Upheld as unknown, with a detail the rationale should carry. The article does describe advancing status as 'bumping' and does document an Undo that reverts completed items — but only within a five-second window. A five-second undo is a mis-tap guard, not the recall of a bumped ticket or the refire of an individual item that the claim describes, and no refire-to-station or reprint action is documented. The finding stands; the rationale should stop implying nothing at all exists. source |
| menu-pricing-dayparting | yes / grade B, upgraded from unknown by the prior verification pass | upheld | The prior pass's quote depended on an inference I wanted to test — whether an order profile fires on a clock or has to be picked by staff. It fires on a clock: 'About order profiles' states 'Order profiles allow you to apply preset settings to orders at the POS, either manually or on an automatic schedule.' Combined with 'Apply a price list to a certain time period, such as happy hour, by linking the price list with an order profile,' scheduled automatic price activation is documented. Caveat for the note: the mechanism schedules prices, and location-timezone handling is not stated anywhere in the price-list articles. source |
| multi-location-price-zones | yes / grade B, upgraded from unknown by the prior verification pass | upheld | Verified against the price-lists article myself. It describes 'preset pricing schemes to apply to menu items based on restaurant location,' gives a worked example of 'five price lists to apply the proper pricing in each location,' and is aimed at operators with 'complex pricing structures for different groups of locations.' The order-profile linkage supplies the per-channel and per-daypart axes. All three axes of the claim are covered by one construct layered over the item record rather than by duplicate items. Worth recording as a limit: 'Once you enable price lists, you cannot use other methods of updating prices.' source |
| reporting-public-api | partial / grade B, cites the developer portal intro | upheld | Upheld on my own retrieval. The portal states 'Access to the Lightspeed Restaurant K-Series APIs is reserved for Lightspeed partners and approved merchants,' and enumerates three routes, none self-serve: approved partners register for the Developer Portal, merchants 'can request access by contacting their Account Managers,' and other developers 'can apply to become partners.' The claim's first half — a documented public REST API over orders, payments, menu and labour — is met; its second half, self-service credentials without a signed partner agreement, is flatly not. Partial with that as the named shortfall is the right value. source |
| reporting-api-not-upcharged | no / grade B, cites the restaurant pricing page | upheld | Confirmed directly and it is worse than 'not at the entry tier.' On the vendor pricing page, 'Raw API access' appears under Premium only — $399/month — and is absent from both Starter ($69) and Essential ($189). API access is therefore gated behind the top published tier, a $330/month delta from entry, on top of the partner-approval gate. Positive evidence of an upcharge, so 'no' is correct rather than unknown. source |
| extensibility-api-access-cost | no / grade B, cites the restaurant pricing page | upheld | Same retrieval, same result: raw API access is a Premium-tier-only line item. The note as written ('a paid-tier line item ... rather than an included capability') understates which tier — it should name Premium and the $330/month delta from Starter, because that number is the decision-relevant one for anyone costing an integration. No separate partner fee, revenue share or per-location API charge is published, which the note has right. source |
| payments-published-rates | no / grade B, cites the payments page | upheld | I closed the loop the prior pass left open. The payments page publishes no rate and redirects — 'View our competitive processing rates on our pricing page' — so I then read the pricing page, which publishes software tiers and a $30/screen/month KDS line and no card-processing rate of any kind. The circular referral is itself the finding: both first-party pages point at each other and neither carries a number. The only published payment figures are a $15 chargeback fee and two-business-day deposits. Positive evidence of non-publication. source |
| order-capture-kiosk-first-party | partial / grade B, cites the QSR marketing page | upheld | Value upheld, grade wrong. The cited URL is a QSR marketing landing page, which is grade D under the evidence rules, not B — the researcher's own note calls it 'one marketing sentence.' I searched the K-Series help centre for kiosk documentation and found none; the 'Supported hardware' article, which does enumerate every other peripheral class down to barcode-scanner model numbers, lists no kiosk device. Partial stands with the shortfall as written; the grade must drop to D. source |
| order-capture-floor-plan-editor | yes / grade B, cites Creating-and-managing-floor-plans-and-tables; note asserts floor plans are assignable to users | downgrade-to-partial | I retrieved the cited article and then the article the note implies. The editor, table shapes, per-table covers and multiple layouts are all documented. The server-assignment half is not: the floor-plan article never mentions users, and Managing users and floor plans (1260804579349) treats users and floor plans as two separate setup tasks, its only staff-related sentence being 'If you have two or more POS users that need similar permissions, such as your servers, bartenders, or managers, we recommend that you set permissions at the user group level' - permissions, not sections. The researcher's phrase 'floor plans assignable to users' is not supported by anything I could retrieve. source |
| order-capture-seat-level | yes / grade B, cites Splitting-a-bill | upheld | Retrieved the article myself rather than trusting the citation. It documents both halves independently: items are assigned to seats during table-service entry, and 'Distribute by seat' then puts each item 'onto a separate check for its corresponding seat' automatically. The claim requires no re-keying, and the documented flow does none. Nothing to downgrade. source |
| order-capture-native-handheld | yes / grade B, cites the Apple App Store listing | upheld | The cited evidence was an App Store page, which establishes that a native binary exists but not that it fires to the kitchen and takes a card at the table. I checked the listing (seller Lightspeed Commerce Inc.; 'take orders on the spot while they're being sent directly to the kitchen or the bar'; iOS 18.5+ and iPadOS 18.5+ so it is genuinely native on both) and then found vendor documentation that closes the payment half: Tap to Pay on iPhone accepts contactless cards and wallets on the handheld with no extra hardware. Value stands; I moved the evidence to the support article because the store listing alone would not have carried it. source |
| menu-pricing-dayparting | yes / grade B, cites About-order-profiles; note already concedes location-timezone handling is not stated | downgrade-to-partial | I retrieved both the order-profile and price-list articles. The automatic-schedule sentence is real and I am not disputing it. But the taxonomy claim is 'Menus, individual items, and prices can be scheduled to activate and deactivate automatically by day and time in the location's own timezone', and three of those four elements are missing from the documentation: menu and item activation/deactivation are never described as schedulable, no day-of-week or start/end time control is shown, and timezone is not mentioned. The price-list article's own worked example is a single happy-hour price change. The researcher named the timezone gap in the note and scored yes regardless. source |
| multi-location-price-zones | yes / grade B, cites About-price-lists | upheld | Retrieved the price-list article. It states pricing schemes apply 'based on restaurant location and order profile', which is exactly the location-group plus channel/daypart matrix the claim asks for, and it operates on one item record rather than duplicates. I checked specifically for the duplication failure mode and the article describes none. This is the strongest of the multi-location cells in the record and it survives. source |
| payments-emv-nfc | yes / grade B, cites Supported-hardware; note concedes Apple Pay and Google Pay are inferred, not enumerated | upheld | The researcher was right to flag the gap and I went looking for it. Support documentation closes the Apple Pay half exactly ('accept Apple Pay, contactless credit and debit cards, and other digital wallets'), and the first-party payments page closes the Google Pay half by naming it alongside the seven card brands. That is a grade-C source for one wallet, which is why I have kept the note explicit rather than laundering it - but this is a table-stakes claim, both wallets are stated by the vendor, and the terminal fleet is documented as chip-and-contactless. Nothing here was invented. source |
| payments-pay-at-table | yes / grade B, cites Supported-hardware; tip prompt asserted to be documented elsewhere without a URL | upheld | The cited hardware page proves a handheld terminal exists but says nothing about tipping, so the researcher's 'documented separately in the tips and gratuities article' was an unverified pointer. I found that article and it holds: customers tip on the terminal screen and confirm the amount there, with configurable percentage or fixed presets. Combined with seat-level splitting from the bill-splitting article, every element of the claim - handheld EMV/NFC, tip prompt, splitting - now has a retrieved source. Upheld, with the evidence pointed at the page that actually carries the weakest element. source |
| payments-chargeback-tooling | partial / grade D, cites the payments marketing page; a self-serve evidence-submission dashboard said to be undocumented | upgrade-to-yes | The researcher looked only at marketing and concluded no dashboard existed. It does, and it is documented: Financial services > Disputes in Back Office lists every current and past dispute with status, reason, deadline and amount, and Challenge dispute opens a drag-and-drop evidence upload with categorised evidence types. That is precisely the claim - a dispute dashboard with evidence submission - at grade B, which clears the differentiator floor. I have kept one honest caveat in the note: evidence is assembled by the merchant, not pre-populated from the POS record, and the $15 figure the researcher quoted from marketing does not appear in the documentation. source |
| payments-p2pe-pci4 | partial / grade D, cites the payments marketing page; no P2PE listing or merchant-facing AOC named | upheld | The value was right but rested on marketing. Lightspeed does publish a merchant-facing AOC, so I fetched and extracted it. It names the K series explicitly and confirms Level 1 service-provider status and P2PE-compliant POI devices - which is more than the researcher found. It also settles the other half against the vendor: the document is a v3.2.1 Attestation for Onsite Assessments, ROC dated January 11 2024. The claim asks for a current PCI DSS 4.x AOC, and this is not one. Partial stands, but on primary evidence at grade A with a shortfall that is now a fact rather than an absence. source |
| hardware-p2pe-terminal | partial / grade D, cites the payments marketing page; merchant SAQ type not stated | upheld | Same correction as the P2PE cell: right answer, wrong evidence. Extracting the published AOC gives primary confirmation that card entry happens on PTS-compliant, P2PE-compliant POI terminals preconfigured by the payment gateways, which is the substantive half of the claim. I searched the extracted document for any SAQ designation and there is none - no SAQ A, no SAQ P2PE-HW, no merchant scope statement at all. The shortfall the researcher guessed at is now verified. source |
| commercial-pci-p2pe-tokenization | partial / grade D, cites the payments marketing page | upheld | I extracted the AOC text rather than relying on the marketing sentence the researcher used. It confirms tokenization is a formally assessed service (CTS) and that K series runs P2PE-compliant devices, which is real support for the first half. The second half - naming the merchant's SAQ so a buyer knows whether they face a 20-question or a 250-question form - is simply absent from every first-party document I retrieved. Partial upheld, moved from grade D marketing to grade A primary. source |
| reliability-pci-dss-4-attestation | partial / grade D, cites trust.lightspeedhq.com; no v4.0.1 AOC version stated publicly | upheld | The trust-center URL the researcher cited rendered as a title with no body for me, so their evidence is not retrievable as cited. I found the actual attestation PDF Lightspeed publishes and extracted its text. It is v3.2.1, ROC dated January 11 2024, and it names the K series in scope - so the version question is now answered rather than open: the attestation covering this product predates PCI DSS 4.x entirely. I am holding at partial rather than moving to no, because a v4 assessment may exist unpublished and asserting its absence about a named business is not something the retrieved evidence supports. source |
| digital-checkout-pci-sca | partial / grade D, cites trust.lightspeedhq.com; script integrity and 3DS said to be unaddressed | upheld | I could not retrieve body content from the cited trust center at all, so I went to the published attestation instead. It confirms the hosted-handling posture at Level 1, and it makes the researcher's guess about 6.4.3/11.6.1 into a certainty for the wrong reason: those are v4 requirements and the published attestation is v3.2.1. On 3DS I was careful - the phrase appears in the AOC only as a printed scope checkbox on the blank form, which is not evidence either way, so I have not credited it. source |
| kitchen-station-routing | yes / grade B, cites Setting-up-Kitchen-Display-System-2-0 | upheld | Retrieved the setup article. Station creation and per-station item routing are both step-by-step operator tasks in Back Office, which is the part of the claim that actually matters - the taxonomy's concern is that a routing change should not require a support ticket, and it does not. I checked whether all four routing dimensions were present and only two are (item, menu category), but the claim is written as an or-list, so it is satisfied. Noted the gap rather than downgrading on it. source |
| kitchen-all-day-counts | yes / grade B, cites Using-the-Kitchen-Display-System-2-0; note itself says modifier detail is listed per item rather than rolled up | downgrade-to-partial | I retrieved the article and the item-level aggregation is unambiguous and well documented - this is not a case of the feature being absent. But the taxonomy claim is 'aggregates outstanding quantities per item (and per modifier)', and the documentation describes modifiers only as accompanying instructions attached to each listed item. Nothing in the Items list produces a modifier count. The researcher wrote that shortfall into their own note and still scored a full yes; naming a gap is not the same as scoring it. source |
| kitchen-sla-alerts | yes / grade B, cites Using-the-Kitchen-Display-System-2-0 | upheld | Retrieved the article and confirmed the Wait Times settings verbatim. Both thresholds are configurable in minutes and both drive a distinct colour state, which satisfies a claim written as 'visual color escalation and/or audible alert'. I looked specifically for whether the thresholds were global rather than per station - they sit inside the per-screen settings, so the claim's 'per station' qualifier holds. No downgrade warranted. source |
| hardware-kds | yes / grade C, cites the pricing page and the status page | upheld | The researcher proved a KDS is sold, not that it does what the claim requires - a pricing line and a status-page component say nothing about station routing or fire timing. I found the KDS 2.0 setup and usage documentation, which establishes both, plus touch-driven bumping and configurable wait-time escalation, all under Lightspeed's own name. Value upheld and the evidence lifted from grade C to grade B, which is where a first-party-versus-integration claim needs to sit. source |
| delivery-3p-injection | yes / grade B, cites Setting-up-the-Deliverect-integration; note already identifies the mechanism as resold Deliverect middleware | downgrade-to-partial | I retrieved the setup article. Orders do reach the POS in real time and I am not disputing the injection mechanism. What I am disputing is scoring it as an unqualified yes when the vendor's own first setup step is 'Request a demo from Deliverect' - the capability is only available through a separately-contracted middleware vendor at unpublished cost, and acceptance still happens on the delivery channel before anything is transmitted. This is exactly the native-versus-partner distinction the verification pass exists to enforce, and the researcher documented it in the note while scoring past it. source |
| digital-first-party-web | yes / grade B, cites Online-ordering; note says it is a paid add-on on the Starter plan | upheld | The cited page barely mentions Order Anywhere, so I retrieved the About and Setting-up articles instead. They establish first-party branding controls and direct POS integration at grade B, and the product page carries the 0%-commission claim at grade C - enough for a table-stakes yes. Two corrections to the record though: the K-Series documentation says 'Order Anywhere is an add-on to existing Lightspeed Restaurant subscriptions' with no tier carve-out, so the researcher's 'paid add-on on the Starter plan' understates the cost, and nothing documents ordering on the restaurant's own domain. source |
| digital-qr-table | partial / grade D, cites the pricing page; attachment to an open check, splitting and tipping said to be undocumented | upgrade-to-yes | The researcher scored this off a pricing-page add-on line and concluded the mechanics were undocumented. They are documented in detail. The K-Series article on placing a table order covers per-table QR codes, tipping with presets or a custom amount, paying online or in person, and splitting by amount and by item - which is every element the claim names, at grade B rather than D. This is one of four cells I moved upward; the researcher simply never opened the Order Anywhere documentation. source |
| order-capture-kiosk-first-party | partial / grade D, cites the QSR marketing page; note concedes no kiosk documentation, form factors, unattended EMV or ADA material | downgrade-to-unknown | I went looking for the kiosk documentation the researcher could not find, and the search itself is the finding: Lightspeed publishes kiosk setup articles for L-Series (Kiosk mode, Setting up a Kiosk iPad, Self-Order Menu) and O-Series (Setting up Lightspeed Kiosk), and none for K-Series, which is the flagship this record scores. The AU Lightspeed Kiosk product page names no POS series, no form factor beyond 'tablet-based', no unattended-EMV behaviour and no accessibility statement. Partial requires naming a shortfall in a capability shown to exist; here the capability's existence on this product line is itself unestablished, so the honest state is unknown with no URL. source |
| digital-kiosk | partial / grade D, cites the QSR marketing page; accessibility and unattended EMV specifics said to be undocumented | downgrade-to-unknown | Same search as the kiosk-first-party cell, same result: for K-Series there is no kiosk documentation at all, only L-Series and O-Series articles and an AU marketing page. The three things this claim actually tests - shared menu and modifier engine, accessible UI, unattended EMV - are each unaddressed in every first-party source I retrieved. Scoring partial on a single marketing sentence implies a sized capability with a named limitation; I could not size it, so it is unknown. source |
| hardware-kiosk | partial / grade D, cites the QSR marketing page; form factors and ADA documentation said to be unpublished | downgrade-to-unknown | This one I could test against a document that would have to mention it: the K-Series supported-hardware article enumerates every peripheral by manufacturer and model - six printer brands, seven payment terminals, scanners, cash drawers, Apple TV for order display - and no kiosk enclosure appears anywhere in it. The AU kiosk page's only hardware sentence is 'tablet-based'. With neither form factor named and no ADA material anywhere, there is nothing to characterise as partial. source |
| labor-clock-in-at-pos | yes / grade B, cites the K-Series API reference | upheld | The researcher's evidence was an API reference showing shift objects and webhooks, which proves shifts exist as data but not that an employee can punch in at the terminal with a PIN - the actual claim. I found the operator documentation: clocking in and out happens in the POS app itself, authenticated by PIN code or scanned QR badge, with no separate hardware. Value upheld, evidence replaced with a source that addresses what the claim asks. source |
| labor-payroll-export-formats | yes / grade B, cites the integrations page, listing 7shifts, Atlas and Restaurant365 | downgrade-to-partial | I retrieved the integrations page. The partner list is real and slightly larger than the researcher recorded (Planday and Push Operations are also listed under payroll), but the page is a grade-C directory of logos, not documentation - it was cited at grade B, which it does not merit. The claim asks for timecards, wages and tips in documented formats or via direct integration, and I could find no first-party article describing what any of these connectors actually carries. Partners under a heading is a weaker fact than a documented export. source |
| extensibility-payroll-export | yes / grade B, cites the integrations page, listing 7shifts, Atlas and Restaurant365 | downgrade-to-partial | Same source, same problem as the labor-side payroll cell, and I am treating them consistently rather than letting one carry the other. The integrations page does name more than two payroll partners, which is why this is partial and not unknown. But the operative words in the claim are 'export natively... without manual re-keying', and a category page listing partner names evidences neither direction of data flow. Grade corrected from B to C because a vendor integrations directory is a feature page, not product documentation. source |
| inventory-native-not-partner | yes / grade B, cites About-Inventory | upheld | This is a differentiator yes at grade B, so I held it to the higher bar and checked the recipe documentation as well as the module overview. Inventory is unambiguously Lightspeed's own module inside K-Series, and recipes are authored in it - the claim's failure mode is a vendor that resells MarginEdge or MarketMan, and that is not what is happening here. I looked hard at the costing half, which is thinner than the record implies (a gross-profit percentage and a suggested sell price, not true ingredient cost roll-up), and noted it rather than downgrading, because the claim's subject is native delivery. source |
| inventory-realtime-depletion | partial / grade D, cites the restaurant marketing page claiming tracking to the ingredient level | upheld | The value was right and the evidence was marketing, so I replaced it. The recipes article documents automatic ingredient deduction on sale, which is materially stronger than the 'to the ingredient level' slogan the researcher cited and moves this from grade D to grade B. It does not get to yes: I read the recipe, stock-level and stock-movement articles looking for modifier-driven depletion and for any statement of timing, and found neither - Understanding stock levels covers only manual input, output and transfer. Both halves of the shortfall are now checked rather than assumed. source |
| reporting-realtime-dashboard | yes / grade B, cites the public status page listing Pulse and Advanced Insights as components | downgrade-to-partial | The cited evidence was a status page, which shows that components named Pulse and Advanced Insights exist and nothing whatsoever about live sales figures - that is not evidence for this claim in any grade. I found the real documentation. Pulse carries the mobile half convincingly, down to a 'time of last update' indicator. The Back Office Dashboard article, which is where the browser half would have to be established, describes graphs and date filters and never states how current the data is. The claim explicitly requires both surfaces, so it lands at partial with the gap named. source |
| reporting-nl-query | partial / grade D, cites the status page; whether it answers numeric questions over the operator’s own data said to be undocumented | upgrade-to-yes | The researcher inferred the feature from a status-page component name and could not tell whether it queried real data. There is a dedicated support article, and it answers exactly that question: the agent reads the operator's Back Office sales reports and renders figures as charts and graphs, and access to tenant sales data is controlled by its own 'Sales report access' permission distinct from general AI access. A help-article-only assistant would need no such permission. Upgraded to yes at grade B. source |
| multi-location-central-menu-publish | partial / grade D, cites the pricing page; a corporate menu publish action with version history said to be undocumented | upheld | The researcher inferred this from a pricing-page bundling line, which evidences nothing about menu publishing. The real documentation exists and is better than they assumed on the publish half - Shared/Global item scoping, share-to-location, and a push that reloads devices at the receiving locations. It is worse on the two things the claim actually tests: the drop-down selects a single location per share action rather than a set, and I found no audit trail of any kind. Partial holds, now at grade B with both shortfalls verified rather than guessed. source |
| multi-location-consolidated-reporting | partial / grade D, cites the restaurant marketing page; ranking and variance flags said to be undocumented | upheld | Cited evidence was a marketing line about managing unlimited locations. I went through the Reports documentation index and found five named Consolidated reports covering sales, products, discounts, shifts and fiscal summary across all linked locations - real grade-B evidence for the aggregation half, which the researcher never located. The comparison half is still missing: none of the consolidated reports is described as ranking stores against each other or flagging variance, and the Pulse all-locations view shows contribution share rather than ranking. Partial upheld on much better evidence. source |
| multi-location-cross-location-loyalty | partial / grade D, cites the restaurant marketing page; a single loyalty balance and order history across the brand said to be undocumented | upheld | I retrieved the business-locations article, which is where this is actually documented, and it both strengthens and constrains the record. Customer profiles genuinely are shared across locations - better than a marketing assertion. But the article goes on to carve out invoices, amounts owed and accounts receivable as per-location, which shows the shared-profile guarantee is not blanket, and it never mentions loyalty balances. Since the claim turns entirely on a single balance chain-wide, partial is correct; the improvement here is grade D to grade B and a shortfall quoted from the vendor. source |
| hardware-commodity-devices | yes / grade B, cites Supported-hardware | upheld | Differentiator yes at grade B, so I retrieved the page and looked for the usual trap - a vendor that names commodity models while quietly requiring its own SKUs. Lightspeed does the opposite: it states outright that buying elsewhere is fine and merely asks that the model be on the supported list, limiting its support obligation rather than the purchase channel. The device list is ordinary Apple retail hardware. The terminal carve-out is genuine but narrow and is already in the note. source |
| hardware-os-platforms | yes / grade B, cites Supported-hardware | upheld | The claim asks only that the vendor name the client operating systems, minimum versions and device specs, and this page does all three with unusual precision - a specific OS floor and an enumerated device-generation list, not a vague 'recent iPad'. I confirmed the version floor is stated as a requirement rather than a recommendation. Upheld without qualification; this is one of the better-documented cells in the record. source |
| hardware-printer-compatibility | yes / grade B, cites Supported-hardware | upheld | Retrieved the compatibility matrix and checked it against the specific test in the claim, which is more than one manufacturer including LAN/Ethernet models. Six manufacturers are listed by name with per-manufacturer connection types, Epson and Star are both among them, and LAN is supported across most of the list. This is the kind of cell that is easy to over-credit from a marketing page; here the underlying matrix genuinely exists. source |
| extensibility-public-api-docs | yes / grade B, cites api-docs.lsk.lightspeed.app | upheld | I loaded the reference anonymously and it rendered in full - endpoint groups, operations and webhook notifications - with no credential wall, which is the whole of this claim. Upheld, and I raised the grade from B to A: this is an API reference, which the evidence rules class as primary technical documentation rather than product documentation. The distinction matters because two other extensibility cells now rest on the same page. source |
| extensibility-order-injection-api | yes / grade B, cites api-docs.lsk.lightspeed.app | upheld | I checked the reference for actual write endpoints rather than accepting 'API creates orders'. Create Local Order and Create To Go Order both exist as POST operations, with check management and payment application beside them - a genuine write API, not a read-only feed with an order-status hook. The claim's downstream half (fires to KDS/printers, lands in reporting) is not asserted in the reference, but the Deliverect integration documents third-party orders reaching the POS device in real time over the same path, so I have not downgraded on it. source |
| extensibility-webhooks-push | yes / grade B, cites api-docs.lsk.lightspeed.app, described as order/payment lifecycle webhooks plus shift, reservation and PMS categories | downgrade-to-partial | I read the notification list in the reference rather than the researcher's summary of it. What is published is Order Notification, Payment Notification and Item Availability Notification - three coarse callbacks. The claim spells out five lifecycle events precisely because a webhook set that omits voids and refunds forces integrators back to polling for exactly the cases that corrupt reconciliation, and neither is exposed. The push architecture is real, which is why this is partial rather than no; the lifecycle coverage the researcher credited is not. source |
| extensibility-oauth-partner-apps | yes / grade B, cites the authorization-overview page, described as OAuth2 authorization-code grant with space-delimited scopes and merchant-initiated authorization | downgrade-to-partial | This is one of the conclusion-flipping cells - genuinely open API versus partner-gated - so I read the authorization page closely instead of accepting the summary. The grant type and the consent step are exactly as described. The gating is what the researcher left out: a client can only request scopes Lightspeed has already permitted it to request, and widening that requires the merchant to go through an account manager. That is a partner-managed permission model, not the operator-granted one the claim describes, and individual revocation - the specific thing that lets an operator fire a vendor cleanly - is not documented anywhere I could retrieve. Three coarse scopes compounds it. source |
| extensibility-accounting-connectors | yes / grade B, cites the integrations page; note itself says journal-entry mapping depth is not documented | downgrade-to-partial | Retrieved the integrations page and confirmed the partner list, which is larger than the record credited. But this claim was written to separate a real GL connector from a CSV dump, and the researcher's own note concedes the mapping depth is undocumented before scoring yes anyway. A directory of logos on a vendor feature page is grade C evidence that partnerships exist; it is not evidence that journals are mapped. Grade corrected from B to C alongside the value. source |
| extensibility-app-marketplace | yes / grade B, cites About-Integration-Marketplace, noted as curated | upheld | Retrieved the article. It documents a browsable directory with filters and an operator-initiated install flow, which is both halves of the claim, and the public integrations page means the listing is visible without a login as well. I considered whether the Back Office location makes it non-public and decided it does not matter here, because the outward-facing directory exists too. The researcher's 'curated' caveat is fair but does not reduce the value - the claim asks whether operators can browse and self-install, not whether anyone may list. source |
| reliability-public-status-page | yes / grade B, cites status.lightspeedhq.com | upheld | Loaded the status page anonymously and confirmed both requirements the claim makes: per-component granularity rather than a single green light, and historical state rather than current-only - the components each render a 90-day history strip. Sixteen named K-Series components is unusually granular. This cell is fine; the problem in this record was the reverse, three other cells leaning on this page as evidence for capabilities it says nothing about. source |
| reliability-247-live-support | partial / grade D, cites the payments marketing page; note doubts live 24/7 phone support at the $69 Starter tier and cites operator complaint themes | upgrade-to-yes | The researcher was right to distrust a marketing banner, but distrust is not a finding and they never located the hours. Lightspeed publishes them in the K-Series help centre: English-language phone support runs every day, 24 hours per day, with regional numbers, and chat is 24/7 in all languages. The claim's test is whether 24/7 live phone support is included rather than sold as a premium tier, and nothing in the documentation gates it by plan. I am not carrying the complaint-theme reasoning forward - unattributed operator sentiment is not evidence in either direction. source |
| reliability-mfa-role-based-access | partial / grade D, cites trust.lightspeedhq.com; merchant-side enforceable MFA said to be undocumented | upheld | The trust-center page the researcher cited returned no body content to me, and in any case it describes MFA on Lightspeed's own internal systems, not the merchant's. I found the K-Series MFA article and the user-group article. Merchant-side MFA does exist, which the researcher missed - but the same article states outright that MFA cannot be enabled by location or by business, only per user. That converts an unverified gap into positive documented evidence that the claim's enforceability requirement is not met. Partial upheld at grade B with a quoted shortfall. source |
| commercial-autorenew-terms-published | yes / grade B, cites the Lightspeed Service Agreement | upheld | Retrieved the agreement and read section 4.2 directly rather than trusting the paraphrase. The renewal duration and the 90-day notice ladder are both there in the published text, which is exactly what the claim asks - terms stated publicly rather than buried in a signed quote. A 90-day window is a long opt-out, but the claim tests publication, not generosity. Upheld. source |
| commercial-data-ownership-clause | yes / grade B, cites the Lightspeed Service Agreement, on the basis that the customer retains ownership of Customer Content | downgrade-to-partial | The researcher read half of section 8.2. Ownership is retained, as they say - but this is a differentiator claim with two conjoined requirements, and the second is that the published terms constrain the vendor's use beyond aggregated and de-identified purposes. Section 8.2 does the reverse: it grants a worldwide, sublicensable and transferable licence to exploit Customer Content for providing, operating, promoting or improving the Products, with the aggregate/de-identified benchmarking language introduced by 'including but not limited to' - an example, not a ceiling. A licence that is sublicensable, transferable and extends to promotion is not a constraint. Downgraded on the vendor's own text. source |
| menu-pricing-modifier-price-by-parent-size | unknown / grade F, placeholder 'No public documentation located during the 2026-08-01 research pass' - cell never examined | resolve-to-no | Read the current 'Understanding modifiers and modifier groups' article. The documented pricing surface is one price per modifier assigned through its modifier group ('By default, modifiers have a price of zero. To add a price to a modifier, assign it to a modifier group'); no per-parent-item or per-size matrix exists among the enumerated settings. Varying by size requires duplicating groups, which the claim wording excludes. Positive absence from the vendor's own configuration enumeration. source |
| menu-pricing-topping-quantity-tiers | unknown / grade F, placeholder - cell never examined | resolve-to-no | The same modifiers article enumerates the only quantity control: required-selection min/max (1-99) times an option can be selected - the add-it-twice pattern the claim distinguishes from tiers. No tier concept, no per-tier multiplier, and production instructions (the kitchen-note channel for 'light'/'extra') explicitly cannot be used with modifiers and carry no price. source |
| menu-pricing-included-allowance | unknown / grade F, placeholder - cell never examined | resolve-to-no | Modifier-group settings are enumerated in full (price per modifier, Default toggle, required with min/max). No included-allowance or overage-only charging configuration exists, and no substitution credit. Differentiator resolved to no on enumeration of the vendor's own settings, not on failure to find. source |
| menu-pricing-countdown-auto-86 | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Item availability documents quantity-based sales restrictions that automatically mark items unavailable at zero, but the auto-86 is described for Order Anywhere and third-party channels, no scheduled auto-restore of the count exists (restore is restock or manual), and the POS-side mechanism is manual snoozing. Two of the claim's named elements present, one absent. source |
| payments-dual-pricing | unknown / grade F, placeholder - cell never examined | resolve-to-no | The Lightspeed Payments FAQ enumerates surcharging as the only card-cost-offset mechanism and never mentions dual pricing, cash discounting or two stored prices; the surcharging and service-charge articles complete the documented payments surface with nothing resembling dual pricing. A domain-wide search for 'dual pricing' and 'cash discount' on the help centre returns nothing. Positive absence: the docs enumerate the alternative (surcharging) and this is not among them. source |
| payments-surcharge-guardrails | unknown / grade F, placeholder - cell never examined | resolve-to-yes | All three named elements are in the vendor's surcharging article: automatic exclusion of debit and prepaid cards (US and Canada), caps enforced at the processor's actual rate and never above 3% US / 2.4% CA, and per-location enablement with Quebec blocked outright. Gates (Lightspeed Payments only, AU/CA/US, At Sale mode, Mobile Tap excluded) are recorded in the note but none touches a claim element. source |
| payments-refund-void-controls | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Role-based gating is fully documented (Order refunds, Partial refunds, Line voids, Cash drawer access, group-scoped discounts). The audit half fails on the vendor's own report: the Cancellations and Corrections report's eight columns contain no user or approver field, and the per-check Journal event log is not documented to attribute actions or to be immutable. Authorization yes, approver-identifying audit log undocumented. source |
| delivery-zone-pricing | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Order Anywhere delivery service profiles document per-zone fee, minimum order and estimated delivery time across multiple radius or custom-drawn zones. The claim's final element - automatic application from the validated customer address - is not described anywhere in the article, so the cell cannot carry yes. source |
| digital-account-saved-payment | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Order Anywhere customer accounts are documented with Google/Apple/email login, digital-wallet card storage and pre-filled checkout. Two claim elements are absent from the vendor's description: saved addresses and one-tap reorder of a previous order. Present but materially short of the claim. source |
| digital-surcharge-transparency | unknown / grade F, placeholder - cell never examined | resolve-to-no | The surcharging article states card-not-present transactions '(e.g. Order Anywhere and manual entry)' will not include surcharges - the vendor positively excludes its digital channel from the POS surcharge configuration. Dual pricing does not exist in the product, and the service-charge article never extends to Order Anywhere. Channel parity is contradicted by the vendor's own documentation. source |
| labor-manager-override-audit | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Audit surfaces exist and are queryable after the fact: per-check Journal event log in the Invoices report and per-device Activity log in Back Office. But no manager-override/approval flow is documented at all, no log is documented to identify an approver distinct from the acting user, immutability is unstated, and the Cancellations and Corrections report has no user column. The attribution core of the claim is undocumented. source |
| labor-tip-distribution-audit-trail | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Per-employee, per-shift tips-received records are documented (clock-out declaration that cannot be changed later; Labor Report with employee-specific tips). The pool halves of the claim are positively outside the system: the vendor instructs staff to 'factor in any tips you receive from, or pay out to, other staff' because pool contributions and distributions are not recorded, and no tip-detail export is documented. source |
| reporting-pmix-modifier-level | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Product Mix Report documents item-level PMIX with quantity, tax-inclusive and tax-exclusive sales, and order-profile/staff/shift/tag filters. Modifier-level rows appear nowhere in the described output, and no daypart filter is documented (the EU-only Filtering Reports Hourly interval is capped at 1-3 day ranges). Item half yes, modifier half undocumented. source |
| reliability-printer-fallback | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Ordered-list automatic failover is documented verbatim ('If this printer is turned off or cannot print, the device will attempt to print on the second printer in the list, and so on'). The claim's alert element is only an optional _BACKUP PRINTER_ header on rerouted tickets; no POS or KDS notification of the failed printer is documented, so yes would overstate the vendor's text. source |
| menu-pricing-dual-pricing | unknown / grade F, placeholder - cell never examined | resolve-to-no | The Lightspeed Payments FAQ enumerates surcharging as the sole card-cost-offset mechanism and never mentions dual pricing, cash discounting or a second cash price per item; the menu documentation stores one price per item per price list. Matches the sibling payments-dual-pricing cell resolved to no on the same enumeration. source |
| payments-offline-decline-liability | unknown / grade F, placeholder - cell never examined | resolve-to-no | The claim is about what the vendor publicly documents, and K-Series publishes no store-and-forward offline payments mode at all - the documented outage fallback is standalone terminal mode, whose payments 'are reported exclusively in the Payments report' with no decline-liability statement and no failed-offline report. The Payments FAQ and the payments troubleshooting article are equally silent. Lightspeed does publish exactly this material for Retail X-Series, underscoring that the K-Series gap is real rather than an indexing miss. source |
| kitchen-printer-fallback | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Printer-to-printer automatic failover is documented verbatim in the printing-profiles article as an ordered fallback list with an optional _BACKUP PRINTER_ header. The claim's KDS half and its no-ticket-loss condition are not documented: the KDS 2.0 setup article's only treatment of a disconnected display is network troubleshooting and a stalled sync count, with no backup-screen mechanism. source |
| digital-google-order | unknown / grade F, placeholder - cell never examined | resolve-to-yes | A dedicated vendor article, 'Google integrations for Order Anywhere', documents provisioning the direct ordering link to the Google Business Profile: customers 'click Order Pickup or Order Delivery to place orders via your Order Anywhere website', with menu and image sync into the profile. The claim's 'Preferred by Business' clause is prefixed 'ideally' and its absence does not defeat the core capability. Grade B vendor documentation carries a differentiator yes. source |
| guest-loyalty-thirdparty-identity-attach | unknown / grade F, placeholder - cell never examined | resolve-to-no | Guest book is the only automatic guest-identity mechanism documented, and the vendor states its scope positively: profiles are built from card data and it 'excludes guests who pay with cash or other tenders'. Marketplace orders are paid on the marketplace and arrive via Deliverect as externally-paid tickets, squarely inside the documented exclusion; no other article claims marketplace identity attach. This is enumeration of the mechanism plus a stated exclusion, not mere absence of evidence. source |
| guest-loyalty-referral-program | unknown / grade F, placeholder - cell never examined | resolve-to-no | The claim requires a native referral mechanic, and the vendor's own enumeration of its loyalty surface is two third-party integration guides (Marsello, Toggle) with no first-party loyalty, rewards or referral product anywhere in the help centre - the same finding the 2026-08-02 adversarial pass recorded for guest profiles. Referral mechanics exist only inside partner products. source |
| inventory-unit-conversion-yields | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Two of the claim's three elements are documented: packaging-to-base-unit conversion with explicit amounts (case = 24 bottles, auto-calculated on purchase orders) and stock-unit-to-recipe-unit conversion via the published formula 'Decrease in stock level = Quantity used in the recipe / Total capacity of one stock unit'. The third element, a yield/waste percentage on raw-to-usable conversion, appears nowhere - the only yield concept is an optional expected-yield field on made-in-batches recipes. source |
| reporting-tip-tax-compliance | unknown / grade F, placeholder - cell never examined | resolve-to-partial | Per-employee declared-versus-earned tip reporting is documented (clock-out declaration prompt, User report, Labor and Business report breakdowns). The other two claim elements are positively outside the product: pooling is handled by staff adjusting their declarations rather than by any pool-distribution record, and the article's tax posture is a referral to 'a tax professional' with no jurisdiction-level tip tax liability summary. source |
| order-capture-drive-thru-timers | unknown / F - K-Series does not document drive-thru lane management or speed-of-service timers | resolve-to-no | No drive-thru capability exists anywhere in the K-Series product surface. The Supported hardware article enumerates every supported peripheral class (barcode scanners, receipt/label printers, network accessories, cash drawers, payment terminals, KDS, Order Display Screen) - no lane hardware, headsets, or timers. The Sales Reports catalog likewise enumerates its reports (Business, Products, Product source |
| order-capture-throttling | unknown / F - Order pacing or rate-limiting to match kitchen capacity is not documented. Check | resolve-to-partial | Per-slot capacity limits exist for the online channel: Order ahead settings include 'Time slot duration: The time in minutes between future orders' and 'Limited orders... In the Orders per time-slot field, enter the number of orders accepted in each time slot duration. For example, accept only five orders every 15 minutes.' Shortfall: no automatic quote-time extension on kitchen load - prep time i source |
| order-capture-catering | unknown / F - Catering or party-order workflows are not documented. Menu and order-capture art | resolve-to-partial | 'Customer invoices allow you to manage catering and wholesale orders within Lightspeed POS... manage orders or services that a customer can pay for at a later time' via an Invoice payment method, Accounts Receivable page and per-customer Balance view; separately, 'Customer deposits allow you to accept advance payments for upcoming events and functions... recorded as a positive balance on the custo source |
| menu-pricing-half-and-half-rule | unknown / F - Fractional-topping or per-section pizza pricing (e.g. half pepperoni / half mush | resolve-to-no | The modifier engine is documented end-to-end and contains no fractional-placement or half-and-half pricing concept: a modifier carries a name, accounting group and SKU; a price exists only via its modifier group ('Add a price for each modifier'), plus Default and min/max selection counts (1-99). No placement (left/right/whole), no per-portion price fraction, and no configurable half-and-half rule source |
| menu-pricing-size-style-matrix | unknown / F - A size/style pricing matrix where the same item carries different prices or modi | resolve-to-no | Item price types are enumerated: 'Single price (default)... Manually-entered price... Manually-entered negative price... No price... Multiple prices: There is a regular base price but can use modified prices based on the order profile selected at the POS... Price as a percentage: The price is based on a percentage of the order's value.' Price variation axes are order profile and price list (locati source |
| menu-pricing-upsell-prompts | unknown / F - Prompted upsells or cross-sell suggestions at checkout are not documented in Ord | resolve-to-partial | Online-channel upsells exist and are configurable: 'Use smart upselling, powered by AI, to recommend specific products... managed through the Upsell Manager in the Back Office' (requires 150+ orders in past 21 days), and since July 2026 operators can 'Override automated recommendations by removing dishes... or pinning high-margin items' under Menu > Menu Upsells. Shortfalls: Order Anywhere only - source |
| menu-pricing-channel-price-books | unknown / F - Channel-specific pricing variants are not documented as a separate feature. Pric | resolve-to-partial | Two documented mechanisms: items support 'Multiple prices' with 'modified prices based on the order profile selected at the POS', and price lists 'apply to menu items based on restaurant location and order profile' with order-profile linking (UEAT integration expects distinct prices on Default/Pickup/Delivery profiles; Uber Eats uses a dedicated order profile). Shortfalls: no percentage-markup rul source |
| menu-pricing-dynamic-pricing | unknown / F - Time-of-day or demand-based dynamic pricing is not documented. Order profiles al | resolve-to-partial | Time-based automatic repricing is documented: 'For your daily drink specials, you link an order profile called Happy hour to a sixth price list, which will automatically apply that pricing at a scheduled time', and order profiles can be applied automatically on a schedule (Adding order profiles, Schedule section). Shortfalls: no demand- or load-responsive pricing and no floor/ceiling guardrail set source |
| payments-qr-guest-pay | unknown / F - QR-initiated payment (guest scans QR to start payment) is not documented. QR ord | resolve-to-yes | 'Scan and Pay allows customers to pay for Order Anywhere orders by scanning the QR code attached to their specific table after their meal. From their mobile device, customers can pay by debit or credit card, split the bill with others, and receive an email receipt' (Order Anywhere Back Office > Settings > Payment settings > Scan and pay). The guest flow ('Scan the unique QR code on your table... T source |
| payments-house-accounts | unknown / F - House accounts or indefinite open-tab balances with accumulated guest credit are | resolve-to-partial | On-account charging is native: orders are tendered to the Invoice payment method (code IKDEBT), accumulate on the Back Office Accounts receivable page per customer, show as a running Balance on the customer profile at the POS, and 'Make invoice' generates a single invoice for all of a customer's pending invoice orders, which can then be settled, viewed, and exported (PDF/CSV/XLSX). ID cards can bi source |
| payments-card-on-file | unknown / F - Card tokenization for repeat purchases on the POS is not documented. Order Anywh | resolve-to-partial | 'By creating an account, customers can add credit and debit cards to a digital wallet in Order Anywhere... payment and contact details will be pre-filled at checkout'; the default card is auto-selected and cards are managed under profile > Wallet. Shortfall: the stored card is usable only inside Order Anywhere online checkout - no documented reuse for phone orders or in-store POS payments (in-stor source |
| kitchen-prep-time-pacing | unknown / F - Predicted or displayed prep times are not documented. KDS 2.0 documents station | resolve-to-no | KDS timing settings are enumerated and are ticket-level lateness flags, not per-item cook-time pacing: 'Enable Timer... Average: Displays the expected wait time for completed orders... Delayed After: the elapsed time after which KDS will flag a ticket as being delayed... Late after: ...flag a ticket as being late' (orange/red pulse). No per-item cook time field exists anywhere in menu or KDS confi source |
| kitchen-order-throttling | unknown / F - Order pacing to match kitchen capacity — holding orders before firing to KDS — i | resolve-to-no | Every documented response to kitchen overload is manual: 'Consider turning off online ordering if your restaurant is dealing with high volumes of in-person customers, facing staffing shortages...' (POS Control center toggle), manually editing profile prep time at the POS 'to better match current production speed', or snoozing items. The only automatic limiter is the static Orders-per-time-slot cap source |
| kitchen-channel-pause-propagation | unknown / F - Pausing one order channel and propagating the pause to all downstream systems is | resolve-to-partial | Item-level 86 propagates natively to Order Anywhere and Uber Eats: snoozing via the OA-Availability web extension on the POS makes items unavailable online, and 'you can snooze Uber Eats in Order Anywhere... you will need to have item availability activated'; sales restrictions auto-mark items 'unavailable in Order Anywhere (or other supported third-party partners)' at zero stock. Uber Eats orderi source |
| kitchen-item-build-screens | unknown / F - Visual assembly instructions or construction diagrams for staff are not document | resolve-to-partial | Beyond ticket line text, production instructions ('preparation notes that can be manually added or automatically tied to an item... the POS will prompt the server to include the relevant preparation info') and modifiers flow to production tickets and KDS stations, and KDS ticket content is configurable (Customer, Order ID, Server, Type, Floor, Order Source, Pickup Time toggles). Shortfall: instruc source |
| kitchen-guest-ready-notification | unknown / F - Automatic guest notifications (SMS/push/email/in-app) when an order is ready are | resolve-to-partial | A guest-facing status board exists: the Order Display Screen 'displays order numbers on an external screen so customers can see the status of their order, whether it is in progress or ready for pickup. The screen updates automatically as POS users manage orders in the... app or on a Kitchen Display System.' Order Anywhere guests also get email status updates ('Your order confirmation, status updat source |
| kitchen-waste-logging | unknown / F - Waste or comps logging from KDS is not documented. KDS documents ticket voiding | resolve-to-partial | Waste can be flagged at the POS via wastage discounts - 'Discount indicates wastage: Enable this if the reason for this discount is food waste... Items that have this type of discount applied will appear as a loss in your reports' - and the Inventory module's Wastage feature records waste events with reasons and value and adjusts stock. Shortfall: neither runs on the kitchen/KDS screen; KDS suppor source |
| kitchen-speed-of-service-reporting | unknown / F - Speed-of-service analytics (order-to-complete time, queue times, throughput) are | resolve-to-partial | KDS Statistics reports 'the total number of products prepared, the average preparation times for each product, and which products are prepared fastest or slowest', with a per-item Heatmap of production time across a 24-hour timeline and by day of week, plus a Modes distribution of production speeds. Shortfalls against the claim: per-item rather than per-ticket/per-station, no percentile figures, a source |
| delivery-route-map | unknown / F - First-party delivery route mapping is not documented. Lightspeed has no native d | resolve-to-no | First-party delivery's complete documented feature set is enumerated in the self-delivery release note - 'Self-delivery enables merchants to: Offer delivery service to customers using your own couriers, Create a geographic delivery zone, and Set a delivery time estimate, fee, and minimum order total by delivery zone' - and the matching Delivery settings in Managing Order Anywhere service profiles source |
| delivery-driver-tracking | unknown / F - Driver location tracking in real-time is not documented for any first-party Ligh | resolve-to-no | No driver-facing app exists. Self-delivery's documented capabilities are limited to 'Offer delivery service to customers using your own couriers, Create a geographic delivery zone, and Set a delivery time estimate, fee, and minimum order total by delivery zone.' No article describes capturing driver GPS or any dispatch screen; for outsourced delivery, couriers belong to Uber Direct/Uber Eats and t source |
| delivery-zones-polygon | unknown / F - Custom polygon-based delivery zones are not documented for first-party delivery. | resolve-to-yes | Delivery areas support free-form map polygons, not just radius: 'Set one or multiple zones to deliver within by clicking Create new... Radius: Choose this option to create a delivery area based on distance. Custom shape: Choose this option to draw a custom delivery area on the map.' Since January 2025, 'you can define multiple delivery zones with customizable fees and minimum order requirements fo source |
| delivery-address-validation | unknown / F - Address validation and automatic zone assignment are not documented. Order Anywh | resolve-to-partial | Delivery ordering is gated by map-defined zones: profiles carry one or more delivery areas (radius or custom shape drawn on a map) each with its own fee, minimum order, and time estimate, so a customer's address is resolved against zones at checkout to price and permit delivery. Shortfall: the docs never describe the validation behavior itself - no statement of geocoding provider, rejection/flaggi source |
| delivery-driver-comp | unknown / F - Driver compensation or settlement reports are not documented. Lightspeed has no | resolve-to-no | No driver entity exists in the product. Self-delivery's enumerated scope is zones, fees, minimums, and time estimates with 'your own couriers'; there is no per-delivery assignment record, no mileage or reimbursement capture, and no payroll export of any kind (labor features are clock-in/out hours plus tip declaration; payroll/scheduling is delegated to the 7shifts integration). Nothing to compute source |
| delivery-cash-reconcile | unknown / F - Cash reconciliation for driver settlements is not documented. Cash drawer and re | resolve-to-partial | Per-user cash accountability exists via user banks: every POS user has a 'user bank, or wallet... set up by default', counted at shift start/end, with the Shift/User reports computing 'Overage: Dollar value based on the discrepancy between what should be in the cash drawer and what was counted' - so a driver clocked in as a POS user gets a per-person over/short. Shortfall: nothing links orders or source |
| delivery-daas-fallback | unknown / F - Fallback from primary delivery service to secondary (e.g. DoorDash to Grubhub) i | resolve-to-no | Dispatch mode is a static per-profile choice, not a rule: 'You can choose to offer delivery using your own staff or through Uber Direct' - the profile's Delivery section is configured to one or the other ('Choose Delivery by my staff... or Delivery via Uber Direct'). No overflow, timeout, or zone-based fallback rules exist; the Uber Direct setup article confirms its delivery range is 'a fixed dist source |
| delivery-86-sync | unknown / F - Syncing 86 (item unavailable) status to all delivery platforms simultaneously is | resolve-to-partial | Item-level out-of-stock sync is documented for Order Anywhere and Uber Eats: items snoozed from the POS (OA-Availability web extension) go 'Currently unavailable' online with timed auto-unsnooze, and sales restrictions mean 'When items reach zero quantity, these items are automatically marked as unavailable in Order Anywhere (or other supported third-party partners)... When inventory is restocked, source |
| delivery-store-pause | unknown / F - Pausing the entire store from accepting new orders across all channels is not do | resolve-to-partial | Uber Eats can be paused from inside Lightspeed: 'The Back Office allows you to pause Uber Eats orders. Navigate to Integration Hub > Online ordering and delivery > Uber Eats and use the toggle... You can also pause orders from the Manage Uber Eats page by clicking Pause orders.' First-party profiles pause from the POS itself (Order Anywhere web extension > Order Profiles > Pause orders). Shortfall source |
| delivery-3p-reconciliation | unknown / F - Reconciliation of delivery orders with third-party payment and fulfillment is no | resolve-to-partial | Order-level payment reconciliation exists: the Online orders report (Operations > Online orders) shows per-order 'Online payment: The total amount paid on the order via the third-party integration', 'Payment over/under: The total amount over or under if the total in the integration doesn't match the total from the POS', 'Total corrections for period', and per-order failure reasons. Shortfall: noth source |
| delivery-injection-error-visibility | unknown / F - Visibility into failed order injections from third-party platforms is not docume | resolve-to-partial | Failed injections are visible per order in two places: the Lightspeed Delivery (Deliverect) dashboard statuses include 'Failed: There was an issue sending the order to Lightspeed', 'Parsed', 'POS failed', 'Receipt not found', and 'Rejected'; the Order Anywhere Orders page shows 'Failed: An error prevented the order from being received at the POS' and the Back Office Online orders report exposes 'I source |
| delivery-tracking-page | unknown / F - A branded tracking page for the customer to monitor delivery progress is not doc | resolve-to-partial | Guests get order-status visibility but not driver tracking: 'Your order confirmation, status updates, and receipt will be sent to the email provided', and the Order Anywhere account Orders page shows 'Any current orders that are pending or in preparation' plus failed orders 'so there is no question whether an order went through or not'. Shortfall: no branded tracking page with courier position or source |
| delivery-promise-time | unknown / F - Promised delivery time calculation and management are not documented. UEAT handl | resolve-to-no | Quoted times are operator-entered constants, documented as such: 'Order preparation time: Choose to set an average preparation time in minutes or omit any time estimate', and per delivery zone 'Estimated delivery time: Enter an estimated delivery time in minutes to display to the customer.' Load-responsiveness is manual: 'you can edit prep time to better match current production speed. Edited prep source |
| delivery-offline-behavior | unknown / F - Behavior during internet outage (e.g. queue orders locally) is not documented fo | resolve-to-no | The claim requires documented offline behavior for delivery; Lightspeed documents the opposite precondition: 'Before you begin fulfilling orders from Order Anywhere, make sure that: Your POS device is online and connected to the internet.' The OA order lifecycle (Pending until 'received by the POS', Failed 'if the Restaurant POS app is not open') shows online orders do not flow during an outage, a source |
| digital-upsell-engine | unknown / F - Intelligent upsell recommendations or prompts in the online ordering flow are no | resolve-to-partial | Algorithmic and configurable suggestions exist in Order Anywhere: 'Use smart upselling, powered by AI, to recommend specific products... These recommendations are based on your sales data and automatically update daily' (Popular items, 3-8 recommendations, requires 150+ orders in past 21 days), and operators can override by 'removing dishes you don't want to feature or pinning high-margin items, d source |
| digital-scheduled-pacing | unknown / F - Scheduled release of online orders to the kitchen (e.g. hold until 30 mins befor | resolve-to-yes | Scheduled orders with per-slot caps: Order ahead supports 'Maximum days ahead', 'Time slot duration: The time in minutes between future orders', and 'Limited orders... enter the number of orders accepted in each time slot duration. For example, accept only five orders every 15 minutes' - full slots stop accepting orders. Release to the kitchen is also paced: a future pickup order syncs to the POS source |
| digital-catering-portal | unknown / F - A catering/event-focused ordering portal with menu customization and team-order | resolve-to-no | Order Anywhere's order types are exhaustively enumerated - 'Select order type: Click this button to switch between Pickup and delivery, Table, and Menu browsing profiles' - and none is a catering flow; no catering menu, minimum, lead-time, quote, or deposit setting exists in OA. The deposits and customer-invoice features live in the POS/Back Office, not in any guest-facing ordering portal, and Lig source |
| digital-voice-ai-phone | unknown / F - Voice AI for phone ordering is not documented. 'Lightspeed AI' exists as a bundl | resolve-to-no | No native voice product and no named certified partner: 'voice', 'phone ordering', and 'AI ordering' return nothing relevant across all 527 help-centre articles (Lightspeed AI is a Back Office analytics chat that answers questions like 'Show me my top-selling items', not an ordering agent), and the public Lightspeed Restaurant integration directory's ordering/delivery listings (Uber Eats, Uber Dir source |
| digital-drivethru-ai | unknown / F - AI-powered drive-thru ordering or lane management is not documented. No drive-th | resolve-to-no | There is no drive-thru mode to attach voice AI to: no drive-thru workflow, hardware, or configuration appears in any of the 527 help-centre articles; the supported-hardware catalog enumerates peripherals with no lane displays or headset systems; and neither the help centre nor the public integration directory names any drive-thru voice partner (checked 2026-08-05). source |
| digital-sms-ordering | unknown / F - SMS-based ordering (send a text to order) is not documented. Order Anywhere is w | resolve-to-no | The platform has no outbound or conversational SMS channel at all. Order Anywhere ordering is web/QR-based; guest communications are email only ('order confirmation, status updates, and receipt will be sent to the email provided'); even gift cards cannot be sent by text - 'Can I send a gift card via SMS text? No, but you can email an online gift card to your customer.' The Back Office 'Text Messag source |
| digital-loyalty-attach | unknown / F - Loyalty enrollment or point earning at digital checkout is not documented. Order | resolve-to-no | Native loyalty instruments (punch, VIP, gift, ID cards) are QR vouchers redeemed by scanning at the POS; nothing accrues or redeems inside the first-party digital flow. The Order Anywhere account is enumerated as wallet cards plus contact info and email preferences - no loyalty balance - and the gift-card FAQ is explicit: 'Can a customer pay with a gift card for an order placed through Order Anywh source |
| digital-promo-parity | unknown / F - Promotions available via POS are also available via digital channels with consis | resolve-to-no | Promotions are defined per channel in separate engines with different mechanics and availability: POS discounts are configured in Back Office Settings > Discounts (with codes, QR application, wastage flags), while Order Anywhere promotions (BOGO, item discount, profile-wide discount) are created separately in the OA Back Office Offers module and 'are only available in Europe, the Middle East, and source |
| digital-guest-data-ownership | unknown / F - Clarity on guest data ownership between Lightspeed and the merchant (CCPA/GDPR i | resolve-to-partial | Bulk self-serve export is documented and unrestricted: Customers > Customer list > Export - 'All data will export by default, so deselect any information you wish to exclude from the file', with file-format choice; Guest book lists can likewise 'export key data to your marketing software'. Shortfall: no published statement that the operator owns the guest records was found - data rights live in th source |
| guest-loyalty-unified-profile | unknown / F - A unified guest profile across all locations is not documented as a first-party | resolve-to-partial | Guest book (Advanced Insights, NA/AU/NZ, sales-activated) 'automatically creates a customer profile with each credit card transaction and updates the profile when the customer returns', tracks 'number of visits across locations', and documents merge behavior: 'If a guest returns... and pays using a different credit card with the same name, their check data and credit card payments sync with their source |
| guest-loyalty-tiers | unknown / F - Guest loyalty tiers (Bronze/Silver/Gold with unlocked benefits) are not document | resolve-to-partial | No native tiers: the built-in loyalty instruments are VIP/gift/punch/ID card batches with no status levels. Tiers arrive only via the documented Marsello integration - 'Marsello streamlines customer engagement by integrating loyalty programs... awarding points for purchases, and offering exclusive perks through VIP tiers.' Shortfall: requires a separate Marsello subscription, and automatic promoti source |
| guest-loyalty-offer-stacking-rules | unknown / F - Rules for combining or stacking multiple promos/discounts are not documented. Di | resolve-to-partial | A precedence rule is documented but fixed, not configurable: 'Item discounts and BOGO promotions take priority over profile-wide discounts for items with the same SKU. Profile-wide discounts do not apply to delivery fees.' POS discount settings (Understanding discounts) expose codes, accounting-group scoping and amount limits but no exclusive-vs-combinable flags or application-order configuration. source |
| guest-loyalty-targeted-offers | unknown / F - Targeted offers to specific guest cohorts (e.g. high-value, at-risk) are not doc | resolve-to-partial | Dynamic audiences exist; offer issuance to them does not. Guest book supports rule-built lists ('Build your own list based on customer or ticket criteria, such as a customer's number of visits'), and 'If you collect customer email addresses, you can also contact customers from a list' or 'export key data to your marketing software.' Shortfall: no native mechanism issues a redeemable offer/discount source |
| guest-loyalty-rfm-segmentation | unknown / F - RFM (Recency, Frequency, Monetary) segmentation for guest targeting is not docum | resolve-to-partial | Two automatic segments plus a computed value score ship with Guest book: 'By default, Guest book automatically includes the Best Guests and Recent Guests lists' (top 100 by spend; most recent visitors) and an 'Estimated Lifetime Value... prediction based on a customer's past behavior.' Shortfalls: no at-risk/lapsed/regular lifecycle segments are computed - anything beyond the two defaults is an op source |
| guest-loyalty-lifecycle-automation | unknown / F - Automated campaigns based on guest lifecycle events (first purchase, churn risk, | resolve-to-partial | No native triggered campaigns exist - Campaigns (Advanced Insights) is a passive date-range sales snapshot, and Daily Digest is a fixed summary email. Lifecycle marketing is delegated to the documented Marsello integration ('rewarding your customers with personalized incentives to keep them coming back'). Shortfall: requires a Marsello subscription, and Lightspeed's own article does not detail whi source |
| guest-loyalty-10dlc-registration | unknown / F - 10DLC (10-Digit Long Code) registration for SMS marketing compliance is not docu | resolve-to-no | There is no SMS sending through the platform to register: guest communications are email-only (order status emails, emailed gift/loyalty cards - 'Can I send a gift card via SMS text? No'), no SMS marketing product exists in the help centre, and '10DLC', 'A2P', and 'campaign registry' appear nowhere in the corpus (searched 2026-08-05). With no SMS channel, the platform neither handles nor documents source |
| guest-loyalty-campaign-attribution | unknown / F - Attribution of orders/revenue to specific marketing campaigns is not documented. | resolve-to-partial | Campaign measurement is a date-window comparison, not redemption attribution: an Advanced Insights campaign is 'a snapshot of your sales data during special events, promotions, or holidays' reporting total sales/visits, average sale, 'the number of new vs. repeat customers, and the profiles of your top spenders', with comparison 'to the average sales for the same day of the week from the prior yea source |
| guest-loyalty-data-export-portability | unknown / F - Guest data export (customer list, transaction history, loyalty points) with port | resolve-to-yes | Self-serve, no fee, no ticket: Customers > Customer list > Export - 'All data will export by default, so deselect any information you wish to exclude from the file. Select the File format... Click Export and the download will start automatically.' Per-customer transaction history exports from Payment > Customer invoices in 'PDF, CSV, and XLSX' (Managing customer invoices), Guest book lists export source |
| guest-loyalty-review-capture-routing | unknown / F - Automated post-purchase review requests (Google, Yelp) routing and management ar | resolve-to-yes | Order Anywhere collects post-order reviews and routes by score: with a Google Business Profile connected, guests are invited to leave reviews, low/ordinary feedback stays in the OA reviews inbox ('gather valuable feedback, address concerns'), and 5-star responses are pushed onward - the reputation dashboard reports 'OA 5-star redirects: The total number of reviews from Order Anywhere pushed to Goo source |
| guest-loyalty-wallet-pass | unknown / F - Apple Wallet or Google Pay passes for loyalty cards, offers, or digital gift car | resolve-to-partial | Apple Wallet passes exist for loyalty instruments: 'customers can easily manage their punch cards, VIP cards, and gift cards in Apple Wallet. Merchants can create electronic loyalty cards or gift cards for customers and email them a QR code to add the card to their Apple Wallet' (Feb 2024). Shortfalls: Google Wallet is not mentioned, and push-updated balances on the pass are not documented (guests source |
| guest-loyalty-privacy-rights-tooling | unknown / F - Tooling for guest GDPR/CCPA rights (access, delete, portability requests) is not | resolve-to-partial | Per-guest locate/export/delete primitives exist: the Customers page lets you 'export customer data, view their transaction history, and make changes to or delete customers' (About customers), the customer-list export is field-selectable, and Order Anywhere guests can self-delete accounts ('Delete my account... Deleted accounts cannot be restored'). A DPA and data-retention policy are published in source |
| labor-photo-punch-verification | unknown / F - Photo verification at clock-in to prevent buddy punching is not documented. The | resolve-to-no | Clock-in authentication methods are enumerated and photo capture is not among them: 'If prompted, enter your PIN code or place your QR code in front of your device's camera to scan it. Note: Add or change employee PIN or QR codes by editing POS users in the Back Office' - the same two credentials (or none) apply at clock-out and login. No photo-at-punch or facial verification option exists anywher source |
| labor-realtime-labor-percent | unknown / F - Real-time labor-cost percentage (labor $ / sales $) display is not documented. L | resolve-to-no | The real-time manager surfaces enumerate their metrics and labor cost percentage is not among them: Pulse's live info boxes are 'Orders, Covers, Voids, Discounts, Comps, Order Average, Cover Average, Table turn time, Refunds, Sales per labour hour' ('Sales per labour hour: The amount of sales generated per clocked in employee hour'). No wage-rate field exists anywhere in Back Office labor docs (ho source |
| labor-overtime-prevention | unknown / F - Alerting or prevention when a staff member approaches overtime hours is not docu | resolve-to-no | The clock-in flow is documented step-by-step (select name, PIN/QR, confirm user shift, optional drawer count) with no warning or block of any kind, and no overtime threshold exists anywhere in Back Office configuration - 'overtime' appears in zero of the 527 help-centre articles. K-Series labor is limited to punches, hours ('All hours worked by employees can be managed from the Back Office'), and source |
| labor-server-performance-metrics | unknown / F - Per-server metrics (avg check, covers, tips, speed) are not documented. Labor re | resolve-to-partial | The Staff Performance report breaks the table down 'by the employees that worked that date' with per-employee Gross/Net sales, Tips, Covers, Cover average, Orders, Order average (average check), Refunds, Discounts, Voids, Comps, Service charges and Losses, filterable by user, user group, shift, and interval; Advanced Insights adds Servers reports and the Daily Digest shows per-employee discount us source |
| inventory-theoretical-vs-actual | unknown / F - Theoretical vs. actual inventory comparison and variance reporting is not docume | resolve-to-yes | 'Discrepancy reports within Inventory allow you to compare your theoretical stock with the actual stock levels, reflecting your most recent stock counts' for a chosen start/end period, per item: Theoretical Stock Level/Value ('after all stock movements recorded'), Last Counted level/value, 'Variance Qty' and 'Variance Value', plus Purchased Qty/Value, 'Consumed Qty: The total quantity of the item source |
| inventory-86-auto-sync | unknown / F - Automatic 86 (unavailability) syncing to POS, KDS, and online/3P in real-time is | resolve-to-partial | Threshold-triggered auto-86 exists at item level: 'Sales restrictions can be used to monitor inventory quantities. When items reach zero quantity, these items are automatically marked as unavailable in Order Anywhere (or other supported third-party partners)... When inventory is restocked, the item automatically becomes available once again' (counter set via POS long-press > Availability > Limited source |
| inventory-mobile-count-offline | unknown / F - Mobile stock counting with offline mode and syncing is not documented. The Stock | resolve-to-partial | Counting is multi-device and concurrent - 'Multiple employees can count together by each resuming the same stock count from different devices... real-time updates across all devices ensure everyone stays coordinated. Changes save automatically every few seconds' with draft resume and per-location item lists. Shortfalls: the documented count flow is search/scroll entry with no barcode or QR scannin source |
| inventory-invoice-ocr | unknown / F - Optical character recognition for supplier invoice line-item scanning is not doc | resolve-to-partial | Native Inventory purchase orders are manual entry (create, place, receive; no scan/ingest option in About Purchase). Invoice ingestion arrives via the documented MarketMan integration - 'a cloud-based inventory and supplier management system... including inventory, purchasing, recipes, vendor payments' - whose invoice product uploads 'via photo, email, or PDF' and extracts line items, matches them source |
| inventory-price-change-alerts | unknown / F - Alerts when supplier prices change on incoming invoices are not documented. Invo | resolve-to-partial | Price history is tracked per item across invoices: Purchase Reports show 'the goods you've purchased, the quantities ordered, price changes over time, and the suppliers', and each item's History page has 'a graph [that] depicts the changes in cost price for the selected item based on previous purchases' with per-order supplier, cost price, and stock level at purchase. Shortfall: no alerting - noth source |
| inventory-waste-logging | unknown / F - Tracking waste, spoilage, or discard with reason codes is not documented. The Pr | resolve-to-yes | 'Use the Wastage feature to update stock levels when items are discarded or destroyed and keep track of waste reasons and the value of what was lost' - Stock management > Wastage provides a dashboard of waste events filterable by date and waste reason showing 'the reason and value behind what was lost', and creating a wastage event adjusts inventory. Waste cost is reported separately from count va source |
| inventory-shelf-life-expiry | unknown / F - Tracking item shelf-life/expiry dates and auto-86 on expiration is not documente | resolve-to-no | The Inventory module's stock-management feature set is enumerated - stock counts, stock locations, par levels, wastage, transfers, purchase orders, batches/produce, and discrepancy reports - and no expiration or use-by date field exists on received or prepped items; 'expiry'/'expiration' hits in the corpus concern card expiry dates, promotions, and MFA codes only (searched 2026-08-05). There is no source |
| inventory-menu-margin-linkage | unknown / F - Automatic menu-item margin calculation from ingredient costs and showing margin | resolve-to-partial | Recipe cost joins to sales per item: recipes carry cost and a Gross Profit % field, and Product Mix / Products reports compute per-item 'Margin (tax excl.): The profit margin for the item: total item sales without taxes - costs' with a Costs column; Magic Menu Quadrant (Advanced Insights) adds popularity/retention menu engineering, and April 2026 Benchmarks & Trends adds market pricepoint comparis source |
| reporting-comps-voids-audit | unknown / F - Detailed audit of all comps and voids by reason, user, timestamp, and authorizat | resolve-to-partial | Reason-coded, permission-gated voids with per-employee reporting: 'Void reasons are used to explain a refund or void applied to an order... Only POS users with the appropriate permissions can refund or void receipts', Discounts and Corrections reports show 'an overview of which void reasons have been applied to refunds or voids' plus discount breakdowns, and Staff Performance attributes Voids/Comp source |
| reporting-cash-over-short | unknown / F - Cash drawer count, over/short reconciliation, and detailed variance report are n | resolve-to-yes | Counted-vs-expected reconciliation at drawer, shift, and employee level: the Drawer report 'shows the cash drawer amount entered at the start of the sales period, payments taken during the shift, cash amount expected to be in the drawer, and the actual cash drawer amount entered when the sales period is closed'; Consolidated Shift Reports compute 'Overage: Dollar value based on the discrepancy bet source |
| reporting-labor-productivity | unknown / F - Labor productivity metrics (sales per labor hour, covers per labor hour) are not | resolve-to-partial | Sales per labor hour from actual punches is native: Staff Performance reports 'Sales per hour: The average amount in sales per hour' with 'Hours worked... based on all staff clock-in and clock-out times on the POS', sliceable hourly/daily, by user and user group; Pulse shows live 'Sales per labour hour'. Shortfall: labor cost as a percentage of sales is unavailable - no wage rates exist in the pro source |
| reporting-server-scorecards | unknown / F - Per-server performance scorecards (tips, avg check, covers, speed) are not docum | resolve-to-partial | Per-server metrics cover average check and more: per-employee Order average (gross/net), Cover average, Covers, Orders, Tips, Refunds, Discounts, Voids, Comps in the Staff Performance table; Advanced Insights Staff reports 'display your sales data by server... view your server's average sales by check or cover and compare a server's performance to an overall average.' Shortfalls: no items-per-chec source |
| reporting-channel-profitability | unknown / F - Profitability analysis by order channel (dine-in, pickup, delivery, online) is n | resolve-to-partial | Revenue splits by channel exist: Product Mix reports break sales down 'by accounting groups, order profiles, statistical categories, and products' (order profiles map to dine-in/takeaway/delivery/Uber Eats/UEAT/Order Anywhere channels), the Online orders report isolates third-party order payments, and item margin (sales minus costs) is computed. Shortfall: no channel P&L net of marketplace commiss source |
| reporting-scheduled-delivery | unknown / F - Scheduled delivery order tracking and fulfillment reporting are not documented. | resolve-to-partial | Scheduled email reports exist but only for a fixed menu of reports: Reports > Reporting automation offers 'Daily revenue, all locations' or 'Daily Settlements, all locations', 'At the end of the day or At the end of the week', with a comma-separated recipient list; Advanced Insights adds the fixed 5:30 AM Daily Digest per location, and Lightspeed Tasks sends daily/weekly checklist summary emails t source |
| reporting-anomaly-alerts | unknown / F - Automated alerts for unusual patterns (e.g. spike in voids, price changes, no sa | resolve-to-partial | Operator-configured threshold alerts exist only in the legacy Stock feature: a rule fires 'When the corresponding stock level goes below the specified quantity' for any stock/product and can 'Send an alert by email', 'Include an email report', or 'Invoke a HTTP end-point' (webhook) - but 'As of June 2023, the legacy Stock feature is no longer available to new customers.' No sales-metric alerting e source |
| reporting-guest-cohorts | unknown / F - Ability to query and segment guests by custom criteria (spend, visit frequency, | resolve-to-partial | Guest-level analytics ship with Advanced Insights: Guest book auto-builds card-based guest profiles with All Time Spend, Average Spend, Visits, Last Visit and 'Estimated Lifetime Value'; rule-based lists segment by spend/visits; Campaigns reports 'the number of new vs. repeat customers'; the Customer scorecard shows per-guest history, favorite items and a 12-month activity grid; Repeat Customer Fa source |
| multi-location-cross-location-giftcard | unknown / F - Gift card purchases at one location, redeemable at any other location in the bra | resolve-to-partial | Liability reporting exists with multi-location filtering: the Gift cards statistics dashboard (Customers > Statistics) reports 'Outstanding balance: The total amount, including refills, currently loaded onto gift cards for the chosen location', with a Location filter that can 'Check the box beside each location', plus Loads and Redemptions activity; gift cards are managed business-wide under Custo source |
| multi-location-multi-brand | unknown / F - Support for multiple different restaurant brands on a single account is not docu | resolve-to-no | Multi-concept operation on one account is positively steered away from: 'Business locations are used when operating the same restaurant concept at different physical sites. If you oversee restaurants with different concepts, we recommend setting up a separate Lightspeed Restaurant business for each.' A POS device belongs to one business location with one configuration; there is no mechanism for tw source |
| multi-location-central-labor-policy | unknown / F - Central definition of labor rules (breaks, overtime, pay rates) applied across a | resolve-to-no | No labor-rule engine exists to centralize: K-Series labor is clock-in/out with PIN/QR, hours in Back Office, and tip declaration; there are no break, overtime, or predictive-scheduling settings at any level - 'overtime' and 'break enforcement' appear nowhere in the 527-article corpus - and nothing is enforced at the terminal. Scheduling and compliance are explicitly delegated to integrations (7shi source |
| hardware-handheld-battery-swap | unknown / F - Hot-swap batteries for handheld devices without powering down is not documented. | resolve-to-partial | The mobile payment terminals have user-removable batteries - the Verifone V400m and e285 SIM-replacement procedures document sliding off the battery cover and removing/reinstalling the battery in the field. Shortfall: the ordering handheld is a standard iPhone (iPhone XS/XR or later per Supported hardware) with a sealed battery, and Lightspeed publishes no rated full-shift battery life for any han source |
| hardware-handheld-lte | unknown / F - Cellular/LTE connectivity on handheld devices is not documented. iPhone XS+ supp | resolve-to-no | The documented outage strategy is 4G on payment terminals, not handheld POS devices: 'Consider using payment terminals with 4G capability for standalone payments in case of outages by your ISP.' POS handhelds (iPhones/iPads) are documented exclusively on the dedicated store LAN - network requirements mandate Wi-Fi RSSI above -67 dBm on a dedicated router, and the only cellular reference for POS de source |
| hardware-drive-thru | unknown / F - Drive-thru-specific hardware (lane status display, order pickup notification) is | resolve-to-no | The supported-hardware catalog is enumerated - Apple devices, barcode scanners, receipt and label printers, network accessories, physical cash drawers, payment terminals, Kitchen Display System, Order Display Screen (plus fiscal modules) - and includes no outdoor menu boards, order confirmation displays, or speaker/headset systems; no timer or speed-of-service measurement exists (KDS Statistics is source |
| hardware-tap-to-phone | unknown / F - Tap-to-Phone payment on a non-iPhone device (e.g. Android tablet) is not documen | resolve-to-yes | 'With Tap to Pay on iPhone, Lightspeed Payments gives you the ability to accept payments directly on your iPhone with no additional hardware required... accept Apple Pay, contactless credit and debit cards, and other digital wallets through a quick tap on an iPhone.' Requirements: iPhone XR or above, iOS 18.4+, screen lock enabled, Lightspeed Payments, app 24.2+; activated under Payment > Payment source |
| hardware-ownership-vs-lease | unknown / F - Hardware purchase vs. lease terms and conditions are not documented. Hardware pr | resolve-to-yes | Hardware is purchased outright, from Lightspeed or elsewhere: 'You can purchase supported hardware directly from Lightspeed. Our online stores are customized for each region' (store.lightspeedhq.com and regional variants), and 'If you choose to buy your hardware elsewhere, we encourage you to purchase the supported models listed in this article' - merchants may even supply their own iPads/iPhones. source |
| hardware-byod | unknown / F - Bring-Your-Own-Device support policy is not documented. Third-party iPad purchas | resolve-to-partial | Bring-your-own-Apple-device is the documented model: the POS app runs on any supported iPhone/iPad on iOS/iPadOS 18+, hardware may be bought 'elsewhere', and per-user security exists (PIN/QR login per POS user, Back Office permission groups; Tap to Pay requires a passcode/Touch ID/Face ID on the phone). Shortfall: nothing addresses staff-owned personal phones specifically - no MDM guidance, data-s source |
| hardware-remote-device-management | unknown / F - Remote management, updates, or troubleshooting of POS hardware is not documented | resolve-to-partial | A device console exists for POS devices: Back Office POS > Devices shows each device's state ('Connected... In background... Disconnected'), sync status (Ok / Remote reload requested / Reload required), Application version, OS version, IP/SSID, with remote configuration reload from the Back Office plus disable, audit, and export; the KDS hub separately lists connected displays with Connected/Disco source |
| hardware-callerid-integration | unknown / F - Caller ID / phone-number lookup integration with the POS (e.g. for phone orders) | resolve-to-no | No telephony hardware or integration exists: the supported-hardware catalog enumerates every peripheral class (scanners, printers, drawers, terminals, KDS, ODS, fiscal and network modules) with no caller-ID or phone hardware; 'caller' appears in zero help-centre articles; and the public restaurant integration directory lists no telephony/caller-ID partner (checked 2026-08-05). Phone orders are key source |
| extensibility-headless-embedded | unknown / F - Headless POS API or embedded checkout for white-label ordering is not documented | resolve-to-yes | The K-Series API's Order and Pay group exposes the transaction engine to third-party UIs: 'Create Local Order' and 'Create To Go Order' POST endpoints inject orders, with operations to apply payments and manage open checks, plus Order and Pay webhooks for lifecycle events. This is how certified ordering fronts drive the POS in production (UEAT web/kiosk ordering posts orders via the external payme source |
| extensibility-data-portability-exit | unknown / F - Data portability and export tools for merchant exit/migration are not documented | resolve-to-partial | Domain-by-domain machine-readable exports are self-serve: full customer list ('All data will export by default') with format choice; items, menus, and price lists import/export in bulk; per-customer transactions and invoices in PDF/CSV/XLSX; report tables export CSV/XLSX; German accounts get the mandated DSFinV-K full POS-data export; and the partner API serves Financials and receipts. Shortfall: source |
| reliability-offline-decline-liability | unknown / F - Declined offline payment liability — who bears the loss if an offline card decli | resolve-to-no | There is no store-and-forward card acceptance to carry liability: during an outage 'most basic order-taking functions will still work offline. But you'll still want to get back online quickly to use your hardware and process card payments' - card payments require connectivity (integrated terminals need the network; the documented outage fallback is 4G standalone payment terminals, which process on source |
| reliability-local-transaction-engine | unknown / F - Local transaction processing without cloud connectivity (e.g. LAN-only mode) is | resolve-to-partial | Local continuity is documented but thin: 'If your network or internet service goes out, most basic order-taking functions will still work offline' (the App Store listing likewise advertises an offline mode), Quebec's WEB-SRM 'works in offline mode right out of the box. All transactions are stored locally on the POS', and the KDS 2.0 hub is a genuinely local server (a dedicated POS 'creates secure source |
| reliability-onsite-install | unknown / F - Onsite installation and training services are not documented. Enterprise tier me | resolve-to-no | Lightspeed's own installation and go-live services are remote: the hardware guide frames installation as self-serve or merchant-arranged - 'You may have hired an on-site professional to set up your hardware, or you might be doing it yourself' - site prep assumes 'installing it yourself, have phone assistance, or use an on-site professional' (one the merchant hires), and even the premium multilocat source |
| reliability-failover-terminal-role | unknown / F - Automatic failover where a POS terminal assumes payment-terminal role during ter | resolve-to-no | The one server-role device in the architecture cannot fail over: KDS 2.0 requires 'a dedicated POS to be the hub' and 'The POS assigned to be the hub for the KDS must always remain on for the system to function. Please keep it charged or plugged in at all times'; if the hub disconnects, screens stall ('If a screen drops offline, its sync count will stall until the connection is restored') and reco source |
| reliability-cellular-backup | unknown / F - Cellular data backup when WiFi fails is not documented. Dual-connectivity strate | resolve-to-partial | Documented for payment continuity only: 'Consider using payment terminals with 4G capability for standalone payments in case of outages by your ISP' - the Verifone terminals carry SIM cards (Settings > Network > Cellular per the troubleshooting guide), so card acceptance can continue standalone over cellular. Shortfalls: this is not automatic failover of the POS - ordering devices have no document source |
| commercial-privacy-dsar-tooling | unknown / F - GDPR Data Subject Access Request (DSAR) tooling for merchants to fulfill guest d | resolve-to-partial | A DPA is published and per-guest primitives exist: the Trust Center holds the 'Data processing agreement', 'Data retention policy', and a 'Data privacy request option'; in-app, operators can locate a customer, export their data (field-selectable customer-list export; per-customer transaction export in PDF/CSV/XLSX) and 'make changes to or delete customers', while Order Anywhere guests can self-del source |
| commercial-dual-pricing-compliant | unknown / F - Dual-pricing compliance tooling (separate cash and card prices, clearly displaye | resolve-to-yes | Automatic surcharging with the compliance mechanics the claim names: 'Automatic surcharging with Lightspeed Payments is only available in Australia, Canada, and the United States'; excluded transaction types include 'Debit and prepaid cards (US and Canada)' - the automatic exclusion the claim requires - plus card-not-present and DCC; the fee is 'a percentage of the total bill added as a separate l source |
| kitchen-order-throttling | no / grade B, cites Fulfilling-orders-from-Order-Anywhere; 'Every documented response to kitchen overload is manual: Consider turning off online ord' | upgrade-to-partial | The cited Fulfilling orders article is a how-to guide and enumerates nothing, so it cannot carry a no. I retrieved Managing Order Anywhere service profiles, whose settings enumeration is self-declared complete ('To view and edit all available settings, click All settings'), and it documents an automatic, operator-configurable order-volume limiter: 'In the Orders per time-slot field, enter the number of orders accepted in each time slot duration. For example, accept only five orders every 15 minutes.' Once that threshold is crossed the channel stops accepting orders for that slot and pushes the customer later - automatic pacing of digital order release against a configured volume threshold, which is the first limb of the claim. The record's own order-capture-throttling cell scores partial on the identical evidence. What is genuinely absent is the load-responsive half: no ticket-time trigger, no automatic prep-time extension, and no throttling of ASAP orders. Partial with that shortfall named, not no. source |
| digital-voice-ai-phone | no / grade C, cites lightspeedhq.com/integrations?product=restaurant; 'No native voice product and no named certified partner: voice, phone ord' | downgrade-to-unknown | The evidence for this no is an integration directory, which is the weakest possible basis for an assertion of absence about a named business - directories omit partners routinely, and the researcher's own caveat conceded the page was only summarised by WebFetch. I tested the enumeration and broke it: lightspeedhq.com hosts an integration page for Voicee, a caller-ID and call-flow telephony product listed as compatible with Lightspeed Restaurant POS (O-Series), which the directory reasoning had not accounted for; Goodcall separately markets an AI phone assistant that integrates with Lightspeed Restaurant via API. Neither source documents unattended AI order capture landing in the POS, so I am not upgrading. But a differentiator no cannot stand on a directory that has already been shown incomplete, and the dossier is K-Series-scoped while the one telephony partner Lightspeed itself lists is O-Series. Unknown at grade F. source |
| digital-sms-ordering | no / grade B, cites Gift-cards-2-0-FAQ; 'The platform has no outbound or conversational SMS channel at all. Order Anywhe' | downgrade-to-unknown | A gift-card FAQ is not an enumeration of a platform's ordering channels, and 'Can I send a gift card via SMS text? No' establishes a fact about gift cards only. I then tested the note's broader premise and refuted it: I retrieved all 528 K-Series articles through the Zendesk Help Center API and Setting up Lightspeed Tasks states that staff 'Receive SMS or email notifications before tasks are due', so Lightspeed does operate an outbound SMS channel. That does not make text-to-order exist - I found no conversational or text-a-link ordering anywhere in the corpus, and Order Anywhere guest messaging is documented as email - but the cited evidence and its stated premise have both failed, which leaves unknown, not no. Note for the record owner: the same refuted premise is the entire basis of guest-loyalty-10dlc-registration, which is scored no against the same gift-card FAQ. source |
| inventory-shelf-life-expiry | no / grade B, cites Stock-management-Inventory; 'The Inventory module's stock-management feature set is enumerated - stock counts, stock locations, par lev | downgrade-to-unknown | I re-retrieved the cited article through the Zendesk article API and read it in full. It is a 700-word overview hub whose body is a link table of six sections (Items, Stock levels, Stock counts, Stock locations, Par levels, Wastage); it never claims to list the module's whole feature set, and it does not mention batches, transfers, purchase orders or discrepancy reports at all, so the note's enumeration is not drawn from it. The remaining support is a corpus keyword search that found nothing, which is absence of evidence. I checked 'Adding production batches' as the most likely home for a date field and it exposes only Recipe, Quantity and Target stock - suggestive but not an item-level field reference. No basis for a positive claim of absence. source |
| hardware-callerid-integration | no / grade B, cites Supported-hardware; 'No telephony hardware or integration exists: the supported-hardware catalog enumerates ever | downgrade-to-unknown | I re-retrieved Supported hardware in full through the Zendesk article API. It does assert completeness for hardware and lists no telephony device, which disposes of the hardware limb of the claim. It says nothing about software integrations, and the claim is explicitly satisfied by 'a telephony integration that pops the customer record and order history at the POS'. The only support offered for that limb was the vendor's public integration directory - a category of source that cannot establish absence - and a help-centre search returning no hits. A web search for a Lightspeed Restaurant caller-ID or telephony partner also returned nothing either way. Positive evidence of absence is missing for half the claim. source |
| reliability-onsite-install | no / grade B, cites Introduction-to-hardware; "Lightspeed's own installation and go-live services are remote: the hardware guide fram | upgrade-to-partial | The researcher read the 'Preparing your site for installation' article for the phrase 'installing it yourself, have phone assistance, or use an on-site professional' and concluded the on-site professional is always one the merchant hires. Reading the whole article refutes that: later in the same page Lightspeed constrains the conduct of its own field staff - 'Lightspeed-contracted technicians cannot drill into or mount hardware on tile, concrete, stainless steel, marble, or granite' - and the Facility and final preparations section is written entirely around a scheduled 'install date' at which someone other than the merchant arrives ('Schedule your Lightspeed Restaurant hardware installation during a time when there is no active construction and your business is not open'; 'Gather all necessary hardware and cables in a central location within your business prior to your installation'). A first-party contracted installer network therefore exists, which the 'no' denied. It is partial rather than yes because go-live support is separately and explicitly remote on the multilocation page ('remote Go-Live support') and the self-install path remains available, so the second half of the claim - in-person go-live support - is not met. source |
| payments-published-rates | no, grade B - Neither first-party page carries a rate. The payments page 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 |
| reporting-api-not-upcharged | no, grade B - 'Raw API access' appears under the Premium tier only on the | 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 |
| reporting-tier-paywall | partial, grade B - The vendor pricing page tiers capability heavily: Advanced I | 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 | partial, grade B - Only KDS ($30/screen/month) is published on the vendor site. | 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 |
| extensibility-api-access-cost | no, grade B - 'Raw API access' is a Premium-only line item on the vendor 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 |
| reliability-menu-build-service | partial, grade B - Enterprise tier advertises 'unlimited launch and consultatio | 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 | partial, grade B - Per-location software tiers published ($69/$189/$399 + Enter | 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-module-unbundling | partial, grade B - Online ordering, Contactless ordering, Reservations, Tasks a | 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 |
| payments-payout-timing | partial / grade B, cites lightspeedhq.com/payments/; note said 'Published: deposits within 2 business days. No next-day or instant-funding option documented.' | upgrade-to-yes | The cited URL 301s to https://www.lightspeedhq.com/pos/retail/payments/ - the Lightspeed Retail product, not Restaurant - so the note rested on a wrong-product page. I searched the K-Series (Restaurant) help centre and found a dedicated article, 'Receiving Instant Payouts with Lightspeed Payments' (updated 2026-07-23), that documents exactly what the researcher said was undocumented: an on-demand Instant payout settling 'within 30 minutes' and an automatic Same-day payout enabled by toggle in Financial Services > Settings > Payouts. The standard schedule is separately published in 'Getting paid with Lightspeed Payments' (6 AM batch cutoff, funds 'within 2 business days'). The claim asks for a published deposit schedule AND a next-day or same-day/instant option; both are now documented in first-party product documentation, so a differentiator yes clears the grade-B bar. Fees and eligibility gates are recorded in the note rather than treated as a shortfall, since the claim asks whether the option is offered. source |
| commercial-interchange-plus-published | no / grade C, cites lightspeedhq.com/payments/; note quoted 'the rate is always the same no matter what card your customer chooses to pay with' as evidence of a blended model | upheld | The cited URL 301s to https://www.lightspeedhq.com/pos/retail/payments/, the Retail product page, so the quoted blended-rate sentence cannot be carried as evidence about Restaurant and I have withdrawn it. I then checked the Restaurant-scoped pages myself. https://www.lightspeedhq.com/pos/restaurant/payments/ states only 'Enjoy competitive rates - no setup costs or hidden fees' and 'View our competitive processing rates on our pricing page.' I fetched that pricing page and scanned its full text for percentages, basis points, per-transaction figures and the string 'interchange': there are none - the page prices software plans and lists 'Integrated payments' as a feature without any rate. The only rate route offered is 'Contact our experts today for a customized quote' for merchants processing over $50K. Because this claim is about what the vendor PUBLISHES, an examined pricing page that publishes no rate is positive, checkable evidence of absence rather than mere absence-of-mention. Value unchanged; reasoning and citation replaced. source |
| commercial-hardware-not-locked | partial / grade B, cites lightspeedhq.com/payments/; note said the POS runs on third-party iPads but 'Lightspeed states merchants cannot use existing terminals due to certification' | upgrade-to-yes | The cited URL 301s to the Lightspeed RETAIL payments page, and I could not locate the 'cannot use existing terminals due to certification' statement on any Restaurant-scoped page, so the shortfall that produced partial is unsourced. I retrieved the K-Series article 'Supported hardware' (updated 2026-07-21) via the Zendesk article JSON API and read it end to end. It meets the claim's own qualifying examples several times over: unmodified consumer iPads and iPhones as the POS device, Epson and Star Micronics ESC/POS receipt printers with individual setup guides, Seiko, Bixolon and Zebra printers, Socket Mobile scanners, and Safescan/APG cash drawers on RJ12. It explicitly contemplates buying elsewhere - 'If you choose to buy your hardware elsewhere, we encourage you to purchase the supported models listed in this article' - and the only restriction stated is scope of support, 'Lightspeed only provides support for the hardware listed in this article.' Integrated payment terminals are indeed a fixed certified list, but the claim as written asks for at least one non-proprietary POS hardware option rather than vendor-only devices, and that is documented comprehensively at grade B. Recorded in the note rather than treated as a shortfall. source |
| order-capture-offline-order-entry | unknown / grade F - rationale: 'The cited source (k-series article 5328889461378) returns HTTP 404 - the offline order-taking claim has no live source' | resolve-to-partial | THE ARTICLE WAS NEVER DELETED; THE ID WAS TRUNCATED. lightspeed-linkcheck's only 404 in 133 citations was .../articles/5328889461378. The live article is .../articles/53288894613787-Troubleshooting-network-issues - the same digits plus a trailing 7 - and this record already cites the live one twice, for reliability-offline-decline-liability and reliability-local-transaction-engine. The sources row that recorded the 404 concluded 'no replacement exists' and this cell was graded F on that premise, while quoting a sentence the live article still carries verbatim. I re-fetched the live article and confirmed the quotation under the heading 'Handling an outage': 'If your network or internet service goes out, most basic order-taking functions will still work offline. But you'll still want to get back online quickly to use your hardware and process card payments.' Resolved to partial rather than yes: the vendor asserts offline order-taking but never enumerates it, so the claim's second half - that the vendor publishes what does and does not work offline - is unmet, and hardware and card payments are explicitly outside the offline envelope. The networking-guide counter-evidence is retained as the shortfall. GENERAL FORM: a 404 whose id is a PREFIX of a live id on the same host is a transcription defect, not a deletion, and no liveness check can see it. source |
| reliability-offline-order-entry | unknown / F - "Third instance of the same 404-sourced claim. For an offline-first competitor analysis thi" | resolve-to-yes | The prior pass had only a 404 and a networking guide. The help centre now carries a dedicated offline article (POS devices section, created after the August census) that states order entry, docket routing and check printing continue on the LAN. Yes at B. source |
| hardware-offline-mode | unknown / F - "Same dead 404 source, same contradiction from the networking requirements doc. Nothing ven" | resolve-to-yes | The claim asks for orders, kitchen printing and cash sales to continue AND for the vendor to name what degrades. Both halves are in one vendor article, in tabular form. Yes at B. source |
| reliability-lan-degraded-multi-terminal | unknown / F - "The networking guide documents peer-to-peer local communication between POS devices over p" | resolve-to-yes | The prior pass read the networking guide's port list as 'supplementary to mandatory cloud connectivity'. The offline article states shared check state across registers over the LAN with the internet down, with an active-device store. Yes at B. source |
| kitchen-offline-operation | unknown / F - "KDS 2.0 setup states 'The POS assigned to be the hub for the KDS must always remain on for" | resolve-to-yes | The prior rationale relied on the KDS 2.0 setup note that the hub POS must stay on. The offline article states directly that the KDS keeps receiving tickets over the LAN when the cloud is unreachable. Yes at B on a differentiator. source |
| reliability-offline-kds-printing | unknown / F - "Assessed and unresolved, with the vendor's marketing and documentation pulling in opposite" | resolve-to-yes | The App Store description and the documentation no longer pull in opposite directions: the help centre now documents kitchen printer and KDS routing over the LAN while offline. Yes at B. source |
| labor-offline-time-punch | unknown / F - "Searched the whole help centre (527 articles via the Zendesk API, 2026-08-05) for offline " | resolve-to-partial | Offline punches are documented as stored locally and uploaded on reconnect. The claim's 'without loss or duplicate entries' half is not documented, so partial. source |
| reliability-offline-card-auth | unknown / F - "K-Series documents 'Standalone payments' and terminal 'cloud mode', where the terminal tak" | resolve-to-partial | Card acceptance during an internet outage is documented, but only through a terminal's own LTE/4G path in standalone mode. That is neither cash-only nor store-and-forward, so partial with the mechanism named. source |
| guest-loyalty-offline-behavior | unknown / F - "The help center references 'offline VIP cards', but that denotes physical/exported card ba" | resolve-to-partial | The vendor does document loyalty behaviour offline (blocked), which the prior pass had not found. It is one sentence rather than the lookup/accrual/redemption breakdown the claim asks for, so partial. source |
| kitchen-order-ready-callback | unknown / F - "Searched the full help-centre corpus (527 articles, 2026-08-05) for KDS-bump-to-marketplac" | resolve-to-yes | The prior pass searched the August corpus and found only POS-side statuses. The KDS 2.0 article carries the sentence directly, and the March 2026 release note confirms it ships by default. Native, documented at B, so yes on a differentiator holds. source |
| order-capture-order-ready-signal | unknown / F - "Searched all 527 K-Series help-centre articles (Zendesk article API, 2026-08-05) for a POS" | resolve-to-yes | The ready signal originates from KDS state and is pushed automatically, which is exactly the claim. Yes at B. source |
| kitchen-course-firing | unknown / F - "Coursing exists in the POS; firing a held course to KDS is not documented." | resolve-to-yes | The prior rationale said firing to KDS was undocumented. Three articles document assign-to-course, hold, and an explicit Fire course action from the server terminal, with the kitchen side showing unfired tickets. Yes at B. source |
| payments-softpos-tap-to-pay | unknown / F - "Tap to Pay on iPhone is not mentioned on the Lightspeed Payments page." | resolve-to-yes | The marketing payments page never mentions it, but the help centre has a full setup article. Native, requires Lightspeed Payments, iPhone only. Yes at B. source |
| menu-pricing-nested-modifiers | unknown / F - "Modifiers exist in the menu and API; nesting depth and per-level min/max/forced flags are " | resolve-to-partial | Min/max and forced selection are now documented, which the prior pass lacked; nesting depth is not, and the API model shows groups holding modifiers rather than groups. Partial. source |
| order-capture-void-comp-controls | unknown / F - "User groups and permissions exist in Back Office and API, but reason codes, manager-approv" | resolve-to-partial | Voids and refunds satisfy all three parts of the claim (reason, permission gate, exception report). Discounts and comps are not shown to require a reason, so partial. source |
| menu-pricing-86-propagation | unknown / F - "API exposes item availability and Deliverect can carry availability, but no documented sin" | resolve-to-partial | A POS-initiated 86 that propagates to the vendor's own online ordering with timed auto-return is documented. Marketplace propagation and latency are not. Partial. source |
| commercial-pci-dss-4-controls | unknown / F - "Trust center documents MFA on Lightspeed's own internal access; no statement on merchant C" | resolve-to-partial | MFA now exists for back-office logins, which the prior rationale said was undocumented for merchants. It is opt-in per user and nothing covers script integrity, so partial. source |
| kitchen-bump-bar-hardware | unknown / F - "The prior 'partial' rested solely on a Merchant Maverick hardware price band, which is not" | resolve-to-partial | The capability exists in the ecosystem through Fresh KDS, not on Lightspeed's KDS, and models are undocumented. Partial. source |
| order-capture-transfer-audit | unknown / F - "Check transfer between servers/tables and its audit trail not documented in the public hel" | resolve-to-partial | Transfer, permission gating and a report trail are all documented; the both-employees audit detail is not. Partial. source |
| order-capture-scheduled-orders | unknown / F - "Partner UEAT handles scheduled/curbside flows; Lightspeed's own scheduled-order fire-time " | resolve-to-partial | Scheduled orders with per-profile lead times are documented; the make-queue fire-time half is not. Partial. source |
| hardware-handheld-purpose-built | unknown / F - "Handheld strategy appears to be iPhone/iPad-based; no purpose-built handheld with publishe" | resolve-to-no | No-audit: the premise was not handed to me; I enumerated the vendor's closed supported-hardware list myself. The claim excludes 'a phone case add-on' by name, and Lightspeed's only handheld is exactly that: an iPhone in a Tableside Case with a magnetic Mobile Tap reader. The smart terminals are payment devices, not ordering handhelds. Positive evidence of absence from an explicitly closed list, so resolve-to-no. source |
| commercial-export-customer-and-loyalty | unknown / F - "Loyalty card batches can be exported to spreadsheet, but a full guest list, point ledger a" | resolve-to-partial | Customer data and card batches are exportable by the operator; the point ledger does not exist natively and gift-card liability export is not documented. Partial. source |
| guest-loyalty-accrual-models | unknown / F - "Re-fetched the K-Series Loyalty section on 2026-08-02: it still contains exactly two artic" | resolve-to-partial | The prior pass saw only the Marsello and Toggle integration articles; the Loyalty cards, punch cards and VIP cards sections are native. One accrual model, support-provisioned, so partial. source |
| extensibility-webhook-reliability | unknown / F - "Webhook CRUD exists across the Staff, Order and Pay, Reservations and PMS groups in the K-" | resolve-to-partial | Webhook authentication is documented at grade A, but it is caller-supplied credentials, not cryptographic signing, and the spec is silent on redelivery. The claim's two halves are both unmet, but delivery auth is a real, documented control, so partial rather than no. source |
| kitchen-expo-consolidation | unknown, grade F — Re-checked the KDS 2.0 setup and usage articles on 2026-08-02 against the claim as written. Stations, per-station routing, an Items list and a Condensed view are documented; an expo or pass screen th | resolve-to-partial | I re-read the whole KDS 2.0 usage article and reject two of the proposal's three supporting quotes while upholding its value. The quote 'confirming the change on one screen does not confirm the change on other screens' sits in Order alerts and is about acknowledging a POS-side modification blink, not about completion state; 'Changes made here only apply to this KDS station and will not be reflected at other stations' sits under Station Management > Order Status and is about configuration, not runtime state. Neither proves the absence of a cross-station completion gate. What does support partial is affirmative and enumerated: a ticket completes at order level ('Once all items in the order are picked up, the order is completed and the ticket is moved to the archive'), the POS receives a consolidated per-course status ('Changes made in the KDS at production centers are reflected on the POS', five statuses Fired/Sent/Preparing/Ready to collect/Completed), and the article closes the Station Management setting list (Ticket summary, Order Status, Color theme, Layouts, Language and time, Wait Times, Routing) plus Quick settings and Order filtering with no expo, pass or aggregator role among them. Routing is per-screen item selection and Order filtering is by POS device or floor, so an operator who splits items across screens gets independently completing tickets. Shortfall: no expo/pass screen role and no documented gate withholding order completion until every contributing station has bumped. source |
| kitchen-recall-refire | unknown, grade F — KDS 2.0 documents advancing a ticket or item to the next status ('bumping') by double-tap or tap-and-hold, and an Undo that reverts completed items — but only within a five-second window, which is a | resolve-to-partial | Verified the Undo limit verbatim in the KDS 2.0 article: 'This button appears for five seconds after the completion of an item. Once the five seconds have elapsed, the completion can no longer be undone. Completed tickets can be found in the archive.' Corroborated by the November 2025 What's New article ('Undo KDS mistakes in seconds ... removes the need to recreate tickets manually'). I also went further than the proposal on the refire half and found it understated: reprinting IS documented in 13 K-Series articles, and it is production-center-scoped, not merely order-level -- the Receipt actions doc says you select which production centers to resend to, 'if you select only Bar, only items assigned to the Bar production center will reprint', and '** RE-PRINT **' is stamped at the top of the copy. That is a selective per-station refire path, which is a stronger present-half than the proposal allowed. Shortfall stands and is now: recall from the KDS is capped at five seconds with no path back from the archive, and reprint selects a production center rather than an individual item. The prior record rationale that reprint is undocumented is affirmatively wrong and should be deleted, not just superseded. source |
| menu-pricing-fractional-placement | unknown, grade F — Targeted searching of the K-Series help centre for half-and-half and fractional topping pricing returns only generic items, modifiers, price-list and check-splitting articles. Modifiers carry their o | resolve-to-no | Upheld, and strengthened with a limit the proposal missed. I re-read the modifiers article end to end. The modifier creation field list is closed and stepwise (Modifier name, Accounting group, SKU, Statistics groups, POS button name and color, Alcohol info) and the group controls are one flat price per modifier, a Default toggle, and a count rule 'you can choose between 1 and 99 selections' -- no multiplier, no fraction, no section, no per-section price. The stated alternative is a second line, not a section: 'Tap Add another item to add this item again with the ability to choose different modifiers.' The missed limit: I read the combos article and 'Modifier groups can only be added to single items, not Combos or Groups', so the combo mechanism cannot be used as a half-and-half carrier either; combos are fixed-price bundles with forced coursing/forced price and no placement axis. Re-measured the zero-hits myself over all 546 en-us article files rather than the flat corpus: halves 0, 'half and half' 0, 'drive'-unrelated 'half' hits are all traffic/discount/gift-card prose, portion hits are meal-voucher and seat-share prose, and pizza occurs once, as an ingredient example (pizza dough) in a recipe article. This is a closed field enumeration plus two stated alternatives, not a bare zero-hit. source |
| kitchen-pizza-fractional-display | unknown, grade F — No fractional topping model is documented anywhere in the menu engine, so there is nothing to render." | resolve-to-no | Upheld on my own read of the KDS 2.0 article. Every rendering surface is enumerated: Ticket Summary (Collection Code, Server, Type, Covers), Ticket Body (course number, number of items, hide/show, three timestamps, 'List and number of each item in the order with action button'), the configurable Ticket summary toggles (Customer, Order ID, Number of customers, Server, Type, Floor, Order Source, Pickup Time), the two Layouts (Direct line view, Equal view), Coursing (as separate chits / single chit), and Seats and items (per-seat plus a Shared heading). No section, half, quarter or graphical placement anywhere. The article also documents that rendering is deliberately lossy for customizations -- 'The KDS shows the customer's specific choice (for example, Medium-Well) but not the name of the modifier group or production instruction itself (for example, Doneness)' -- which is the opposite of unambiguous sectioned rendering. Independently confirmed there is no upstream model to render (see menu-pricing-fractional-placement). Both the model and the rendering are affirmatively absent. source |
| delivery-dispatch-board | unknown, grade F — The 'one screen' delivery view consolidates third-party orders, not driver dispatch. No dispatch board documented." | resolve-to-no | Upheld, and I closed the two escape routes the proposal left open. The Delivery Dashboard article uses closing language twice -- 'The Orders page contains the following columns' (Pickup time, Location, Order ID, Channel, Receipt ID, Status) and 'Orders can have the following statuses on the Dashboard' (Accepted, Cancel, Canceled, Delivered, Failed, New, Parsed, POS failed, Preparing, Printed, Receipt not found, Received, Rejected) -- and neither set contains a driver, an assignment, an elapsed-time-per-order or an out-for-delivery state. Escape route one, self-delivery: I read the self-delivery article and its capability list is three bullets -- 'Offer delivery service to customers using your own couriers', 'Create a geographic delivery zone', and 'Set a delivery time estimate, fee, and minimum order total by delivery zone'. Own couriers are assumed, never rostered, assigned or batched. Escape route two, Uber: Uber Direct and Uber Eats are explicitly a third-party courier network ('powered by Uber's world-class courier network'), i.e. the DaaS handoff the claim excludes. I re-measured 'driver' across all 546 article files myself: 25 occurrences, every one a printer driver. 'Courier' occurs 7 times in 5 files, all of them Uber, the customer-facing delivery note field, or the self-delivery bullet above. No driver roster, no run batching, no dispatch screen. source |
| digital-group-ordering | unknown, grade F — Assessed and unresolved. The feature K-Series documents under the name Group Ordering ('Setting up and using Group Ordering', retrieved 2026-08-04) is a staff-side counter tool - servers ring up each | resolve-to-no | Upheld on my own read. Lightspeed occupies the term with a different mechanism, which is the strongest form this kind of absence takes. The article opens 'The Group Ordering feature helps your staff process and prepare orders for groups of customers ordering at the counter' and the flow is staff-side throughout: assign a table, ring each guest, 'Process your customer's payment and complete the sale as usual', and the only thing pooled is the kitchen ticket on a timer -- 'Once one of the ordering timers reaches its limit, the system will send the Group Order to the kitchen at the same time and on the same ticket.' The entire configuration surface is two drop-downs, 'Set the max time between orders' and 'Set max time since first order'. I then checked the digital channel where a shareable cart would have to live: across all 546 en-us articles 'shared cart' and 'spend cap' occur zero times, 'shareable' once and 'invite' once, neither in an ordering context, and 'group order' appears in only three files -- this one, POS configurations, and the floor-plan article. Every element of the claim (shareable link, multiple participants adding to one order, per-person or total spend cap, split or single payment at the end) is absent from the one feature the vendor named for the job and from Order Anywhere. source |
| kitchen-prep-forecasting | unknown, grade F — Inventory 'Produce' covers batch production and recipe management; a demand-forecast-driven prep list is not documented." | resolve-to-no | Upheld and independently re-measured. The Lightspeed Tasks manager capability list is closed and entirely manual: 'Create, assign, and schedule checklists of tasks', 'Configure response types: photo, text, count, signature, or temperature', 'View completion logs and receive checkpoint reports'; checklists are assigned by user tag, and the daily summary reports completion rate, never a predicted quantity. I re-ran the forecast measurement over all 546 article files myself and got a tighter result than the proposal: 'forecast' occurs in exactly three files and every occurrence attributes forecasting to something other than the first-party product -- the Purchase Report ('valuable information for budgeting and planning, which can help your restaurant better forecast its future purchasing needs', i.e. historical reporting), Deputy ('past 12 months of sales data into Deputy so that you can start seeing forecast trends'), and Tenzo ('a restaurant management and data forecasting app'). 'prep list' and 'production plan' occur zero times; par levels are static reorder points; and I read the Lightspeed AI agent article to rule it out -- it 'pulls sales data from reports in the Back Office and presents it in an easy-to-read format' and answers support questions, generating no prep quantity. The stated alternative is third-party, which is what makes this a no rather than a zero-hit. source |
| digital-native-app | unknown, grade F — No branded native consumer ordering app documented; partner UEAT offers branded apps." | resolve-to-no | Attacked first as instructed; the value survives but one of its two legs must be re-described. First I confirmed the analyst's new premise myself: the fabricated /pos/restaurant/zzz-invented-205-c/ page in the cache is a real soft-404 whose body title is 'Page not found - Lightspeed' at 207,345 bytes, so a 200 with real content under /pos/restaurant/ does mean existence. But that same control page carries the ENTIRE site navigation verbatim, including the Restaurant product list and the Golf 'Website & App' entry -- so the proposal's phrase 'the same page's own Restaurant product navigation' is wrong: that list is global chrome, not a page-specific enumeration. It is still evidence, and arguably better evidence, because it is the vendor's site-wide Restaurant product index. I corroborated it on a second, independent leg the proposal did not use: the www sitemap union enumerates 60+ /pos/restaurant/* pages including one per product (order-anywhere, inventory, kitchen-display-system, tasks, tempo, reservations, payments, accounting, hardware, payroll, pricing) and contains no restaurant app page, while it does carry /golf/website-app/ and /golf/website-app/custom-websites/. The affirmative vendor statement holds on the page I read: 'Let guests view your menu, order and even pay by scanning a QR code. No need for them to download an app.' Finally I checked the docs: across all 546 en-us K-Series articles every one of the 25+ App Store / Google Play references is to the staff-facing Lightspeed Restaurant POS app (apps.apple.com/.../lightspeed-restaurant-pos-k) or to iPadOS update hygiene -- there is no consumer app of any kind. The claim explicitly excludes 'only a mobile web page', so this cannot be partial. I did not use the proposal's UEAT sentence: the UEAT integration article describes an online ordering channel and says nothing about branded apps, so that supporting statement should be dropped. source |
| order-capture-drive-thru | unknown, grade F — No drive-thru order flow documented." | resolve-to-no | Attacked second as instructed. I reject the proposal's load-bearing leg and uphold the value on different evidence; this is the weakest of my five nos and its citation should be re-homed off the marketing page. Rejected leg: 'the page's feature enumeration is exactly four items and contains no drive-thru anything' is a marketing omission, the weakest possible evidence of absence, and the two third-person FAQ sentences I verified ('these establishments offer quick counter, drive thru ordering or both' and 'Takeaway and drive-thru options are common in this model') are industry description, not a disclaimer. What I upheld it on instead: the order-typing model is documented and closed. The KDS 2.0 article states 'These types are based on the accounting groups set up in the Back Office. Dine-In, Delivery, and Pickup are the default accounting groups and can be changed according to your needs' -- so an order type in K-Series is a renameable accounting-group label with no lane, window, sequencing or pull-forward semantics attached, and the KDS ticket field set (Customer, Order ID, Number of customers, Server, Type, Floor, Order Source, Pickup Time) has no lane or vehicle concept. I re-measured over all 546 en-us article files myself: drive-thru 0, 'drive thru' 0, drive-through 0, and 'lane' 0 in any operational sense. And across the 283 O-Series articles the single family-wide occurrence is a printer-routing example ('dine-in, pick-up, takeaway, drive-thru, etc, and want to send their docket printing to specific printers'), which confirms the documented limit: drive-thru exists in this vendor's documentation only as an order-type label for print routing, never as a flow. A drive-thru module would be a product with a marketing page and a doc set; the vendor has neither. source |
| guest-loyalty-native-email-sms | unknown, grade F — Marketing/loyalty is largely partner-delivered (Kangaroo Rewards, Loyale, Freebees, DYNE)." | resolve-to-partial | Upheld, with one supporting statement corrected and one stronger piece of evidence added. Corrected: the proposal says 'no SMS campaign capability is documented anywhere in the K-Series help centre' -- that is not true as written. SMS does exist in the product: the Lightspeed Tasks article documents that staff 'Receive SMS or email notifications before tasks are due'. It is a staff operational channel, not a guest marketing channel, so the shortfall survives, but the sentence must be narrowed to guest-facing SMS. Added, and it is affirmative rather than an absence: the gift-card FAQ asks 'Can I send a gift card via SMS text?' and answers 'No, but you can ...' -- the vendor denying guest SMS send in its own words. On the email half I verified the Guest book article myself: it is a segmentation and export tool ('You can also create a guest list to segment and export key data to your marketing software'), the outbound sentence is a single unelaborated line ('If you collect customer email addresses, you can also contact customers from a list.') with no template, schedule, audience or send-mechanism documentation anywhere, and the module is gated exactly as quoted ('available to Lightspeed Restaurant customers in North America, Australia, and New Zealand. To get access to this feature, contact your Sales Account Manager'). I also checked the obvious escape routes across all 546 articles: 'newsletter', 'Mailchimp' and 'email marketing' occur zero times, and the Advanced Insights 'Campaigns' feature is analytics of a promotional period, not a send engine. Shortfall: guest-facing send is email only, its mechanism is undocumented, the documented pattern is export to a third-party ESP, and the module is a sales-gated add-on unavailable in Europe. source |
| guest-loyalty-consent-management | unknown, grade F — Checked 2026-08-03: the K-Series Loyalty section still contains only the Marsello and Toggle integration articles, so loyalty/marketing consent capture would live in the partner product, and the 'Man | resolve-to-partial | Upheld on my own read, and the enumeration is genuinely closing rather than illustrative: the article says 'The following settings are the details available to enter in a customer's profile' and then lists all thirteen -- First name, Last name, Email, Company, Tax ID, Language, Primary phone number, Secondary phone number, Contact permissions, Notes, Primary home address, Secondary home address, ZIP, City, State. Consent is the single boolean quoted ('When enabled, this customer agrees to receive email communications from the restaurant. When disabled, the customer will not receive emails.'), revocation is a staff-side toggle ('toggle Allow email notifications'), and the article carries the operational instruction 'Always ask for permission before entering a customer's contact information in Lightspeed Restaurant.' Shortfall confirmed and now measured against a closed field list: two phone-number fields exist with no SMS or phone consent flag beside them, and there is no consent timestamp and no source-of-consent field. Revocation is honoured by any means only in the sense that a staff member can flip the toggle; there is no guest-initiated revocation path and only one channel to revoke. Partial is also the corpus's modal value here and no record in the atlas scores this yes. source |
| guest-loyalty-ai-offer-recommendation | unknown, grade F — 'Lightspeed AI' is bundled from the Essential tier and an AI Assistant component appears on the status page, but no documented offer-recommendation feature." | resolve-to-partial | Upheld with a third shortfall added that the proposal missed and that matters. Verified the article in full -- it is short and I read all of it. The shipped feature is real and documented, not roadmap: 'Use smart upselling, powered by AI, to recommend specific products to customers in your menu', managed through the Upsell Manager under Back Office > Offers, data-gated at '150+ overall orders in the past 21 days', and self-refreshing ('based on your sales data and automatically update daily once enabled'). Missed shortfall: the recommendation is not personalised at all. The only documented toggle is 'Popular items', which surfaces global best sellers at the top of the Order Anywhere menu with a minimum of 3 and maximum of 8 -- the same list for every guest, computed from aggregate sales volume, not from any individual's history. So of the three things the claim names, offer content is satisfied only in the weak sense of choosing which items to promote, target audience is not merely unselected but structurally absent, and there is no send timing because there is no send. I also ruled out the other AI surface: the Back Office Lightspeed AI agent article describes a reporting and help-centre chat that 'pulls sales data from reports in the Back Office and presents it in an easy-to-read format', with no offer generation. Partial, not yes and not no: a documented shipped AI recommender exists, but it merchandises a menu rather than targeting a guest. source |
| labor-break-compliance-by-state | unknown, grade F — Assessed and unresolved. 'Clocking in and out' (retrieved 2026-08-04) documents the entire native time-clock flow - PIN/QR clock-in, optional cash counts, tip declaration at clock-out - and never men | resolve-to-no | Upheld and extended past the single article the proposal cited, which on its own would have been a zero-hit. I read the clock-in/out article and the time-capture lifecycle really is start-and-end only: clock in (username, PIN or QR, optional cash count), clock out (transfer open orders, 'Tap Yes on the pop-up asking you to end your user shift', optional cash count, optional tip declaration, optional user summary print). No break punch appears at any step. I then read the downstream surface the proposal did not check, About Hours, and it closes the loop: the Hours section 'provides an overview of all user shifts logged in and out on the POS' with an Overview page, a Monthly hours page, manual session add/edit, export, print and an Audit view -- a shift-level ledger with no break, meal, rest or premium-pay dimension. Finally I measured across all 546 current en-us articles myself: 'meal break' 0, 'rest break' 0, 'overtime' 0, and every 'break' occurrence is a Canadian tax-break news item. There is no scheduling module for a rule set to attach to; scheduling and labour compliance are documented as partner integrations (7shifts, Deputy, Push Operations, Tanda). A closed lifecycle plus a stated third-party alternative, not a bare absence. source |
| labor-minor-labor-rules | unknown, grade F — Assessed and unresolved. K-Series documents no native scheduling module at all - scheduling is delivered through the 7shifts and Planday integrations - so the claim's enforcement-at-scheduling half h | resolve-to-no | Upheld on my own read of the POS users article. The identity captured when creating a user is enumerated stepwise and is exactly username, first name, last name, email address (used for Lightspeed Tasks notifications), plus POS access credentials (PIN, QR code) and permissions; the quick actions are Duplicate user and Edit business locations, and the lifecycle ends at Disable user. There is no date of birth, no age and no minor or job-class status field, which is what makes this a no rather than an absence: an age-based maximum-hours rule, a prohibited time window or a school-day limit has no attribute to be expressed against. I confirmed the field-level absence independently across all 546 en-us articles -- 'date of birth' occurs zero times and the sole 'minor' occurrence is 'a copy of an item with minor changes' in the item-duplication article. And neither half of the claim has a home: enforcement at scheduling requires a scheduling module, which K-Series does not ship (rostering is delegated to 7shifts, Deputy, Push Operations and Tanda), and enforcement at clock-in requires a break/limit engine, which the clock-in article shows does not exist. source |
| labor-qualified-tips-w2-reporting | unknown, grade F — No documentation of Treasury tipped-occupation codes or W-2 Box 12 TP / Box 14b handling for TY2026." | resolve-to-no | Upheld; I read the tips article in full and it is exhaustive on this subject, covering enabling tips, credit/cash/receipt/bar-tab/pre-payment tipping, tipping after payment, automatic gratuity via order profiles, declaration, reporting, distribution and suggested-tip settings. Three affirmative findings, not a zero-hit. One, the declared figure is structurally collapsed across tender types and cannot be split: 'Servers should enter the total tips they took home via all payment methods after paying out tips to other staff', 'The declared tip amount should be the total you leave with across all payment methods', and 'Tips can only be declared when clocking out, and declaration amounts cannot be changed later.' A single self-reported net number that already nets out tip-outs cannot yield a cash-versus-charged qualified-tip split. Two, the tip outputs are enumerated -- Labor Report, Business Report, Receipt Report, plus the POS User report -- and none is a payroll or tax filing artefact. Three, the vendor affirmatively assigns the reporting obligation elsewhere: 'Report declared tips to the tax authority for your region as required', 'Speak with a tax professional to ensure you follow the correct rules for declaring, distributing, and reporting tips in your region', and for distribution it points to a third party, 'Consider using a third-party service, such as TipJar'. No Treasury tipped-occupation code, no W-2 Box 12 code TP and no Box 14b construct appears here or anywhere in the 546-article corpus, where 'payroll' occurs in only three files (this one, the Deputy integration and one other). source |
| inventory-vendor-catalogs-edi | unknown, grade F — Purchase orders and supplier tracking exist; no named broadline EDI catalog (Sysco/US Foods/PFG) integration is documented." | resolve-to-no | Independently read Creating purchase orders in full. The supplier object is created from a name and an email address only ("click New supplier, enter their name and email"), the transmission step is an email form with To/From/Cc/Bcc, and the article names its own alternatives explicitly - "If you order items from your suppliers through other means, such as a supplier website, you can still receive those items into inventory by creating a PO and opting to skip the email", plus an Ordering profile setting "To update stock levels only" that suppresses the email entirely. A stated alternative channel, not a bare absence. I re-ran the corpus test with word boundaries rather than substring (the proposal's grep form would also match "edited"): EDI as a whole word occurs in ZERO of the 546 K-Series and 283 O-Series articles, as do Sysco, US Foods, Performance Food and Gordon Food. No distributor catalog, no punchout, no electronic invoice return. source |
| inventory-shelf-life-expiry | unknown, grade F — Downgraded on audit 2026-08-06. The prior 'no' rested on the Stock management (Inventory) help-centre page, which is an overview hub of links ('Visit these articles to learn more about using Stock ma | resolve-to-no | The proposal's citation does not bear the weight put on it: About Inventory is an 812-character overview with a three-row table and promises nothing about completeness, so I re-sourced the finding. The module's own navigation article, Stock management (Inventory), enumerates the section piece by piece - Items, Stock levels, Stock counts, Stock locations, Par levels, Wastage - with no date-bearing feature and no expiring-soon view; its Items entry gives the per-item attributes as supplier, measurement type and packaging formats, with no expiry or use-by field. The alternative is stated affirmatively in the Wastage article: "There are various reasons that items can go to waste: expired ingredients, broken objects, or an issue caused by staff error. Use the Wastage feature to update stock levels when items are discarded or destroyed", with a free-text reason and notes - after-the-fact loss capture, not date-driven rotation. Corpus check: "use-by", "best before", "shelf life" and "shelf-life" occur zero times across both corpora, and every "expiration" hit is a card, certificate, connection-code or voucher expiry. source |
| inventory-bar-partial-bottle | unknown, grade F — Partner integrations (WISK, BevSpot, Kegtron) address bar inventory; native partial-bottle weighing is not documented." | resolve-to-partial | REJECTED the proposed yes. The Stock levels decimals are real but they are THEORETICAL depletion, not partial-bottle counting: "Decrease in stock level = Quantity used in the recipe / Total capacity of one stock unit", applied when a production batch is made. I then read the article the claim's counting limb actually turns on, Performing stock counts, and the physical count is entered in whole units - "enter the exact item quantity in the Units field or use the + / - buttons to adjust the value by one" - with no documented decimal, fraction or weight entry, and no scale integration anywhere in either corpus. So an open bottle is depleted on paper by recipe but there is no documented way to count it back, which is exactly the pour-cost variance this claim exists to measure. Two further limits: the capability sits in the paid Inventory add-on, a separately purchased module with its own login ("Log in to the Inventory module with your Lightspeed credentials"), and no bar-specific pour or partial-bottle workflow is documented. Shortfall: recipe-derived fractional stock levels only, in a paid add-on; whole-unit stock counts; no scale or weight capture. source |
| reporting-sales-forecast | unknown, grade F — Benchmarks & Trends exists as a component; forward forecasting in the Lightspeed UI is not documented (7shifts does the labor-side forecast)." | resolve-to-no | Independently verified and it survives on a stated-alternative basis. I swept both corpora for "forecast" and found five hits, every one of them a partner: Deputy ("facilitate labor forecasting by sending real time data to Deputy"; the backfill job is "uploading your restaurant's past 12 months of sales data into Deputy so that you can start seeing forecast trends"), Tenzo ("a restaurant management and data forecasting app" that "automatically pulls and aggregates Lightspeed data"), Quantaco in the O-Series partner list, and one Purchase-report sentence saying the report "can help your restaurant better forecast its future purchasing needs" - a human reading history, not a generated forecast. The direction of data flow is the finding: Lightspeed exports the history so the forecast can be computed in someone else's product. No forward daypart or hourly projection exists in the K-Series report set. Limit recorded: only part of the www marketing surface is on disk, so this is a finding over the help centre and the O-Series corpus. source |
| payments-processor-choice | unknown, grade F — Rests entirely on Merchant Maverick naming Dejavoo/Worldpay, Cayan, BridgePay. Lightspeed's own payments page documents the opposite posture (certified-firmware terminals only, BYO terminal explicitl | resolve-to-partial | REJECTED the proposed no; its load-bearing sentence is false. The K-Series Supported hardware article carries a section headed "Payment terminals and card swipers" stating "Third-party payment processors will provide you with encrypted card readers and payment terminals compatible with their services" and "Lightspeed Support can assist with the integration between third-party payment terminals and Lightspeed Restaurant", then enumerates supported terminals under five named processor tabs - CCV, SIX (Worldline), SumUp, PayPal and Verifone - with per-model, per-country detail (Yomani Touch XR, Desk 3500, Lane 5000, SumUp Air, PayPal Reader, Zettle Reader 2) and an explicit PAX not-supported list. That is precisely the documented processor list the claim asks for. Understanding payment types corroborates it structurally: "Third-party payment processors" is a first-class integrated payment type - "if you use an integrated third-party credit card processor, you might create a payment method named Credit card... Lightspeed Restaurant knows to communicate with your chosen processor" - and Setting up the PayPal Reader is a full grade-B setup guide for a non-Lightspeed processor. Shortfall making this partial rather than yes: Service Agreement I.5.3 mandates the in-house rail where available - "Provided Customer (i) uses the Products (ii) is located in a jurisdiction in which Lightspeed Payments is offered and (iii) is eligible... Customer must use Lightspeed Payments unless otherwise agreed to by Lightspeed in writing" - I.5.4 charges a volume-tiered monthly Fee to anyone processing elsewhere, the supported third-party list is regional (Switzerland, France, EMEA, APAC), and every terminal Lightspeed itself sells is Lightspeed Payments only. source |
| commercial-processing-not-bundled | unknown, grade F — Same weak footing, and the specific penalty figure is now contested. Cross-checking turned up claims that the $99/month gateway fee belongs to the legacy U-Series (Upserve) platform, and separate thi | resolve-to-partial | REJECTED the proposed no, on the same evidence as payments-processor-choice: the POS demonstrably can be operated with a third-party processor and Lightspeed documents how. Supported hardware names CCV, SIX (Worldline), SumUp, PayPal and Verifone as supported third-party processors with per-model terminal tables and says "Lightspeed Support can assist with the integration"; Setting up the PayPal Reader walks through creating a Zettle payment-method type and pairing the reader. On the premise I was asked to test, I confirmed in the agreement text that the $99 fee is NOT general: Section II is the product-specific section and its numbered items are 1. Lightspeed eCom (E-Series), 2. Lightspeed Restaurant POS (U-Series), 3. Hardware, 4. Lightspeed Payments, 5. API Access; the $99 sits at II.2.2, inside the U-Series item and immediately after II.2.1's Meraki router licensing - a SKU letter the record's own identity section does not list among K/O/L/G. It may not be cited as the K-Series penalty. What does bind K-Series is general Section I: I.5.3's "Customer must use Lightspeed Payments unless otherwise agreed to by Lightspeed in writing", conditioned on jurisdiction and eligibility, and I.5.4's volume-tiered monthly Fee, whose tiers I could not retrieve because /legal/transaction-fees/ routes to regional PDFs on pdf.lightspeedhq.com, which is robots-barred. Shortfall: a contractual mandate plus an uncosted monthly penalty on top of a genuinely documented and supported third-party path. source |
| commercial-rate-increase-clause | unknown, grade F — No rate-increase cap or penalty-free-exit clause located. Reviewers report mid-relationship price increases." | resolve-to-no | Read the agreement myself; both limbs fail against affirmative clauses rather than against silence. I.5.2: "by renewing their subscription, whether implicitly or explicitly, Customer is obligated to pay all of the Fees due under the renewed contract at the then-current prices for the duration of the Renewal Term", and "any discounts offered under the initial Order Form shall not carry over or pertain to the Renewal Term" - a right to reprice at will, the opposite of a cap. I.4.2 auto-renews "for a duration equal to the Initial Term" and closes "Except as otherwise specified herein, Customer may not terminate this Agreement prior to the expiration of the Term"; I.13.5 prices the exit as an Early Termination Fee summing unpaid non-recurring Fees, all recurring Fees for the remainder of the Current Term, and clawed-back software and hardware discounts. The only exit is a 90-day non-renewal notice at the term boundary, not exit on an increase. Scope limit recorded rather than hidden: card-processing rates sit outside this document - II.4 says "Lightspeed Payments is a separate payment processing service governed by a different set of agreements", referenced only in the Order Form and merchant application, neither published - and I verified by byte length that /legal/service-level-agreement/, /legal/dpa/, /legal/lightspeed-terms/ and /legal/terms-of-service/ are all soft-404s at exactly 177,085 bytes, versus 292,583 for the real Service Agreement. The finding is therefore over the fee framework Lightspeed does publish, which contains no cap and no increase-triggered exit. source |
| commercial-hardware-purchase-outright | unknown, grade F — No published purchase-vs-lease statement or hardware price list on the US site." | resolve-to-yes | Tested the storefront objection and it does not bite here: this claim is about what a merchant can BUY at a published price, which is exactly what a storefront is competent to establish. Both legs re-checked. Contract: II.3.1 "Customer shall pay the purchase price set forth in the Order Form or website (as applicable)", and II.3.2 hands the ongoing relationship to the manufacturer after 30 days - sale semantics throughout. I re-ran the proposal's lease/rental grep with word boundaries, because its substring form matches "please" and "current"; done properly, "lease" appears once and "rental", "rent" and "leasing" zero times, so the no-lease finding survives its own bad grep. Prices: store.lightspeedhq.com publishes outright USD figures on its own front page - 16-inch Cash Drawer APG Minota $129.00, Smart Terminal Hospitality (US) kit $234.00, Smart Terminal with Printer Hospitality $399.00, Lightspeed Stand with Payments $199.00, Apple iPad 11-inch $449.00 - across a 70-URL catalogue of terminals, printers, cash drawers, scanners, stands, tablets and networking, with no lease or rental SKU. KDS and ODS need no proprietary screen (an iPad; an Apple TV plus any HDMI monitor). The one multi-year hook is conditional on a discount, not on purchase: II.3.5 binds hardware "being provided to the Customer at a discount (or free of charge)" to 24 months of POS and Lightspeed Payments use, with repayment of "the value of the hardware, plus shipping costs" otherwise - a list-price buyer incurs none of it. source |
| hardware-rma-sla | unknown, grade F — Searched for published warranty terms and replacement SLAs on 2026-08-05: 'warranty', 'RMA', 'advance exchange', and 'replacement' (in a hardware sense) return nothing in the 527-article help centre; | resolve-to-partial | Read Section II.3 myself and first confirmed it is a general product-specific item, a sibling of the E-Series and U-Series items rather than U-Series-scoped, so it does bind this record. One limb is met: II.3.2 publishes a term - "Lightspeed warrants to Customer that new Hardware will be free from defects in workmanship and materials... for thirty (30) days from the date that Hardware was shipped to Customer as original end-user" - short and non-transferable. The other limb is refused rather than merely absent: the remedy is discretionary and untimed ("Lightspeed may, at its sole option, repair or replace Hardware"), return-first rather than advance-exchange ("Hardware must be returned in good condition in the original packaging", "Charges for returning Hardware shall be for Customer's account", "A restocking fee may also apply"), expires into a manufacturer handoff ("Following expiration of the Warranty Period, Customer must contact manufacturer for any repairs or replacement"), is made exclusive by II.3.4, and is capped by I.16's "LIGHTSPEED EXPRESSLY DISCLAIMS ANY SPECIFIC SERVICE LEVEL WARRANTIES OR COMMITMENTS", glossed in the plain-language column as "Our Products are sold without any service level warranties or commitments". Shortfall: a 30-day defect warranty with no replacement SLA, no stated turnaround, no advance exchange, and a possible restocking fee on returns. source |
| reliability-hardware-replacement-sla | unknown, grade F — Searched 2026-08-05 for a replacement/advance-exchange program: no help-centre article mentions hardware replacement turnaround, advance exchange, or warranty service ('replacement' hits concern card | resolve-to-no | Held to the higher bar because "or purchasable" gives this claim a second limb the contract alone cannot close, so I searched for the purchasable half independently: across the 546 K-Series and 283 O-Series articles, "advance exchange", "advanced exchange", "loaner", "replacement device" and "return merchandise" occur zero times, and every "next business day" hit is a transitory-order, payout or webstore-dispatch reference, none a hardware replacement commitment. Against that the contract is affirmative in the other direction: II.3.4 "REPAIR OR REPLACEMENT ARE THE EXCLUSIVE REMEDY PROVIDED IN CONNECTION WITH THE PURCHASE BY CUSTOMER OF THE HARDWARE" forecloses an additional program; II.3.2's remedy is at Lightspeed's sole option, requires the unit be shipped back at the customer's cost with a possible restocking fee, and ends after 30 days at "Customer must contact manufacturer for any repairs or replacement"; and I.16 disclaims specific service level commitments entirely. An exclusive-remedy clause plus a documented manufacturer handoff is positive evidence of absence, not a zero-hit over a floor. source |
| payments-offline-store-and-forward | unknown, grade F — Offline card store-and-forward is documented for Lightspeed Retail X-Series, not for Restaurant K-Series." | resolve-to-no | A conclusion-flipping cell, so I read the whole 4.5 KB article rather than the quoted lines. It is structured as two tables, Offline functionality and Offline limitations, and the split is unambiguous. On the offline side the tender set is "Cash, check, or any custom 'Manual' payment types (e.g., 'Paid Offsite,' 'House Account') can be accepted and recorded in the POS" - no card. On the limitations side, "Integrated payments (Lightspeed Payments) are not handled in real-time. The actual payment transaction must be handled using the terminal in standalone mode, with LTE/4G connection", and both connectivity scenarios repeat "Payment terminals without a cell network connection will not function". Store-and-forward exists, but for order data only: "the active POS will log all activity and send its stored data once the internet connection is restored". No per-transaction or cumulative offline card limit is offered because no offline card capture is offered, and the vendor names its own alternative - a cellular-backed terminal run standalone, outside the POS. The stated alternative is what makes this a no rather than an absence. source |
| reliability-sync-conflict-handling | unknown, grade F — Assessed and unresolved. The claim asks whether the vendor documents conflict-resolution behavior for edits on two devices during a network partition; nothing of the kind was found in the surfaces ch | resolve-to-partial | Verified against the full article. Lightspeed does document partition behaviour in some detail: with the LAN up and the internet down, "Passive POS devices can still send data to active POS devices, but the active devices cannot forward the data to the cloud", "The active POS maintains a cached, local version of essential data", and "Orders opened on one POS will sync to other POS. Data will be stored locally, in the Active Device(s)"; with the LAN also down, "No communication between any devices (passive or active) is possible" and "only the active POS can take orders and payments". Divergence is therefore structurally limited by an active/passive model. SHORTFALL, and the reason this is not a yes: nowhere does the article state what happens when two devices do produce divergent edits. Last-write-wins, merge and operator prompt are all absent from the text; the single-active-device arrangement is described as an operational consequence of connectivity, never as a stated conflict-resolution policy; and reconciliation on reconnect is described only as "send its stored data once the internet connection is restored", with no account of what the cloud does if it disagrees. source |
| multi-location-org-hierarchy | unknown, grade F — API scopes access by business location; a named three-level enterprise > region > location object is not documented." | resolve-to-no | Read Navigating business locations end to end. The model really is two levels and the article is explicit about the boundary: "Business locations are used when operating the same restaurant concept at different physical sites", and the escape hatch for anything above that is a separate tenant, not a group object - "If you oversee restaurants with different concepts, we recommend setting up a separate Lightspeed Restaurant business for each." The article then enumerates the entire cross-location model as three lists - Global features (accounting groups, order profiles, production instructions, user groups, payment methods, discounts, void reasons, transfer operations), Shared features (users, customers, reporting) and Local features (reporting automations, floor plans, hardware, POS devices, production centres, printing profiles, POS configurations, hours, reporting shifts, invoices, add-ons and integrations) - and no entry in any of them is a region, group, district or brand. Reporting has exactly two scopes: "While each business location generates its own set of reports, Location reports aggregate data for a comprehensive overview of all locations." Permissions scope to a per-user list, not a group: users "only have access to the location they were created in by default", widened by editing "the business locations they are assigned to". A named workaround plus an enumerated sharing axis is positive evidence of absence. source |
| hardware-kiosk | unknown, grade F — Assessed and unresolved. The claim requires countertop and freestanding form factors plus documented ADA compliance. The only hardware statement Lightspeed publishes about its kiosk is 'Tablet-based | resolve-to-partial | REJECTED the proposed no; both its legs are the wrong instrument and its conclusion is contradicted by the corpus already on disk. Supported hardware enumerates PERIPHERALS a merchant attaches to an iPad - scanners, printers, cash drawers, network gear, terminals, KDS, ODS - so a kiosk that is itself an iPad running an app could not appear in it whether or not it exists; and the 70-URL store sitemap enumerates what Lightspeed sells, not what it supports. Meanwhile Lightspeed ships a first-party kiosk: Setting up Lightspeed Kiosk documents "the Lightspeed Kiosk O-Series app", installed from the App Store, "compatible with our supported iPad devices", enabled in Back Office under Features where you "Select how many kiosks you want to activate for the site. The total pricing will automatically update based on the number of kiosks selected", paired "with an available Lightspeed Payments terminal", drawing its catalogue from the same Online products list, with configurable inactivity timeout, logo, banner, welcome message, and Lightspeed Loyalty on the kiosk. The K-Series corpus corroborates a kiosk channel at partner level - the UEAT integration article defines a fixed order-profile code, "Kiosk (if applicable): UEATKI" - and O-Series partner lists carry Foodhub, Tabin and TabSquare self-service kiosks. Shortfalls, hence partial not yes: the first-party kiosk is a separately-priced O-Series add-on rather than a K-Series flagship product; only one form factor is documented (an iPad app - nothing on countertop enclosures versus freestanding pedestals); and there is no ADA or accessibility statement on either surface. source |
| guest-loyalty-redemption-fraud-controls | unknown, grade F | resolve-to-partial | AMENDED from the proposed no/B to partial/B. I re-fetched all five cited articles myself from the Help Center API (537 en-us articles, 2026-09-15) and confirmed both batch tables verbatim, including their completeness framing ("For a description of each field, view the following table" / "see the table below") and the permission table's "Check the box beside each permission you wish the user to have". Those two batch tables ARE closed enumerations of the only configurable rules on the only first-party loyalty instruments, so the absence of a velocity cap, a cooldown and an approval step is positively evidenced, not merely unfound. The no still fails, for a reason the proposal raised and then dismissed: the claim reads "enforces loyalty fraud controls SUCH AS redemption velocity limits, manager approval ... and flagging of employee self-redemption, with an audit log" - the list is illustrative, so documented loyalty-instrument fraud controls of another kind defeat a flat absence. The proposal quoted "Revocation status" and "Last activity" and characterised them as "the only integrity primitives published"; per-card locking is squarely an anti-abuse control on a loyalty instrument, and the surface the proposal never checked settles it. Managing ID cards (updated 2026-02-18, an article the proposal does not cite, and ID is one of the four card types inside the same Loyalty cards module) documents the revoke ACTION - "Find the ID card you wish to revoke and click Revoke card" - and an explicit per-card audit trail: "Click on the UUID in the Back Office to review the card's lifecycle, including when it was linked to a customer, when it was sent to the customer's email, and any revocations." A per-card lifecycle log plus revocation plus a last-used timestamp is a materially limited version of the claim, which is partial with a named shortfall, not no. Note that "including" there is an OPEN enumeration, so I cannot assert the lifecycle log excludes redemption events either - which independently sinks the no. I did not take the fallback to unknown: the proposal offered unknown only against the permission table being non-exhaustive, whereas partial here rests on positive evidence of PRESENT capability, not on the strength of an enumeration. I also cleared the leads the task named: card revocation and validity dates are real and are now in the note; the Logbook article is Advanced Insights staff communication ("Use Logbook for staff communication ... customize your Logbook questions, add new checklists, and require shift notes", NA/AU/NZ sales-gated), not an audit log; the only "supervisor" hit in the corpus is a German tax-audit aside in Drawer reports. No double count: guest-loyalty-accrual-models cites About Loyalty cards for the punch-only accrual model and this cell cites the card-search/revocation surface for integrity controls - different propositions, and the shortfall here cross-references rather than re-scores the accrual finding. Grade B (vendor help centre), which is the ceiling for this evidence; the claim is niche weight, so no grade floor applies. SEPARATE DEFECT FOUND, not fixed here: the stale premise the task flagged survives in three OTHER published cells - guest-loyalty-referral-program (no/B: "There is no native loyalty product for a referral mechanic to live in"), guest-loyalty-stored-value-gift (partial/B: "There is no first-party guest-profile product in the K-Series help centre") and guest-loyalty-tiers - all of which assert the Loyalty section is only Marsello and Toggle. About Loyalty cards contradicts that, so those three rationales need re-binding. source |
| hardware-selfpour-scales | unknown, grade F | resolve-to-partial | Refetched the cited article myself (HTTP 200, 80,347 bytes, 2026-09-15) and confirmed all twelve proposed quotes, including both enumerated modes, against raw bytes. Three failed as raw substrings and each is a benign encoding artefact, not the welding trap: "Hardware > Production centers" is entity-encoded >, "Set the Destination IP address in the following format" is split by an <em> close, and "Dirmeier is an automated drink dispensing system" is split by an <a href=dirmeier.de> wrapping the first word inside a single <p>. No quote spans a table cell or list boundary; the two modes are genuine sibling <li>s under "The integration supports two modes:". The self-refutation challenge fails on inspection of the conjuncts. The claim is a hardware-integration premise over an enumerated disjunction (self-pour walls / flow meters / liquor pour spouts) plus an operative behavioural test (pours post to a tab automatically). The second conjunct is refuted, and I strengthened that refutation rather than accepting the proposer's silence argument: a tokenised census of the article body returns zero for check, tab, bill, receipt and automatically, and my own search of the help centre for "pour" returns exactly one article - this one - so there is no second first-party surface where pour-to-tab could live. But the first conjunct genuinely survives with first-party setup documentation, so the partial does not shortfall every conjunct and is not self-refuting. Peer consistency confirms the line: this corpus already scores order-first dispense-control integrations as partial in five verified records (agilysys partial/B on a Berg bar gun, linga partial/C on AndroBar, spoton partial/B, touchbistro partial/B, lavu partial/C), and reserves yes for records where the pour actually drives the check - aloha's drink-dispenser docs raise "Item #### not found in database" on an unmapped pour, gotab ties RFID self-pours to the tab. Lightspeed shows the opposite direction, so partial is where it belongs, and rejecting it would contradict five verified peers. The flow-meter partners do bear on the claim, but only to widen the hardware premise: they are the only Lightspeed-named hardware that literally matches the claim's enumeration, and they do so at grade C as directory tiles with count-0 help-centre coverage, while their stated function is variance reconciliation - so they corroborate the premise and independently confirm the inversion. Amendments to the note: corrected the Compatibility citation, which the proposer quoted as contiguous text when the markup splits it with <strong>, and which for BeerSAVER covers U-, K- and L-Series rather than K-Series alone; recharacterised Dirmeier as dispense control rather than self-pour, so the literally enumerated hardware sits at C not B; added my own bounds (search "pour" count 1, partner names count 0, 246-entry directory zero for PourMyBeer/iPourIt/Table Tap) and the fuzzy-OR poison that makes the large counts unusable. Grade B stands: both the met conjunct and the shortfall rest on the vendor help-centre article, not on the C tiles. Robots checked on both hosts I fetched - k-series-support.lightspeedhq.com bars /search, /hc/*/search and /integrations but not /hc/en-us/articles/ nor the /api/v2/help_center/articles/search.json path I used, and www.lightspeedhq.com bars /rest/, /pdf/ and /ls/ but not /integrations/. No double count: this cell is the only row in the record resting on Dirmeier; inventory-bar-partial-bottle cites the Stock levels article and is independent. Original value was unknown/F, so in verification.jsonl this is a resolve-to-partial, not a downgrade. source |
| guest-loyalty-stored-value-gift | partial, grade B | upheld | Re-scored on the merits after the note's stated premise was falsified. The premise 'there is no first-party guest-profile product in the K-Series help centre for a balance to attach to - the Loyalty section carries only the Marsello and Toggle integrations' is wrong twice over: the Loyalty section it cites is 'Partner integrations > Loyalty', a sibling of a separate first-party tree 'Add-ons and integrations > Lightspeed Loyalty cards' whose About Loyalty cards article says 'The Loyalty cards module included with Lightspeed Restaurant K Series allows you to offer discount, gift, punch, and ID cards'; and customer profiles are documented as a native object in at least 14 en-us articles. I re-fetched all nine Gift cards 2.0 articles myself (2026-09-15) and confirmed the customer-assignment quotes verbatim. That resolves the first conjunct in the vendor's favour, so the note had to be rewritten - but the value does not move, because the second conjunct (cross-location redemption) is still nowhere stated for 2.0, and the vendor demonstrably knows how to state it: it answers exactly that question for ID cards ('No, ID cards are not restricted by location') and for the legacy cards, and is silent for 2.0. Transferring the legacy 'visible at all sites' line to 2.0 would be over-crediting, and it is about search visibility rather than redemption in any case. Partial/B stands with a corrected and now correctly-named shortfall. source |
| guest-loyalty-referral-program | no, grade B | upheld | The verdict survives, its stated basis does not. The note's premise - 'There is no native loyalty product for a referral mechanic to live in: the help centre's entire Loyalty section is two third-party integration guides' - mistook one section for the whole loyalty surface. I re-fetched the cited section (34839005050651) live on 2026-09-15 and it does still list only Marsello and Toggle, but it sits under 'Partner integrations', and a separate 'Add-ons and integrations > Lightspeed Loyalty cards' tree (section 8352184481179) holds 24 first-party articles across VIP, punch, gift, gift cards 2.0 and ID cards. So I re-derived the absence from the native product itself rather than from its supposed non-existence, and it is in fact better evidence: a closed four-item enumeration of instruments plus closed rule tables on each, which I read verbatim, with a tokenised whole-corpus control behind it. Note on that control: an inline regex with over-escaped word boundaries returned false zeros for 'reward' and 'points', so every count here was re-run through the tokenising script; 'refer' alone is a trap word, matching 36 articles that all use it as 'refer to this article'. No/B stands on replaced reasoning. source |
| digital-voice-ai-phone | unknown, grade F | upheld | Re-probed as instructed. The en-us URL the rationale leaned on is a 404 today, but this is a locale partition rather than a deletion, so the citation re-binds to a live page rather than an archived one: the AU copy is live at 200 and Wayback also holds four captures of it. Two corrections to the rationale while re-binding. First, it implied Voicee was a missed AI-telephony partner; reading the page verbatim, Voicee is caller-ID and call routing on O-Series, which neither satisfies nor refutes this claim - its only load-bearing role is to prove the en-us directory is incomplete, which is what keeps the cell off 'no'. Second, the Goodcall sentence needed bounding: I ran a Wayback CDX domain scan for goodcall on lightspeedhq.com and got zero rows, so no Lightspeed-published Goodcall page has ever existed as far as the archive is concerned. Value stays unknown at grade F - the claims row keeps a rationale and no url field, per the grade-F rule; the AU URL is recorded in notes.json and named inside the rationale as the page retrieved. source |
| order-capture-kiosk-first-party | unknown (F) — never examined | resolve-to-partial | Resolved from unknown to partial, with the first pass's shortfall widened and two of its citations corrected. The kiosk half is real and fully documented, so `no` would be a false statement; but the shortfall is not merely 'O-Series only'. I established independently that O-Series is the Kounta AU/NZ line (support.kounta.com 301s to o-series-support; every O payment partner is Tyro/Windcave/Eftpos NZ/Westpac/Smartpay; 'United States' appears in 1 of 281 O articles) and that the kiosk is not sold in the record's primary market: https://www.lightspeedhq.com/au/pos/restaurant/kiosk/ is 200 while the US, UK, CA and NZ paths all 404, the US/CA/NZ 404 bodies being byte-identical and their stripped text exactly 4,823 characters, the same as a deliberately fabricated control path /pos/restaurant/nonexistent-control-page/. The AU navigation carries 'Kiosk New' and 'Loyalty New' under Hospitality; the US navigation carries neither. I also corrected the first pass's third-party comparison: https://www.lightspeedhq.com/integrations/kurve/ 404s - Kurve is published at /uk/integrations/kurve/ - and a second Category: Kiosk partner, INFI, was missed entirely. The accessibility conjunct fails on a corpus that is a complete publisher manifest. Grade floor is not engaged: this is a differentiator but the value is partial, not yes. |
| digital-kiosk | unknown (F) — never examined | resolve-to-partial | Resolved from unknown to partial. I checked the self-refutation test first: the claim has three conjuncts and two survive on quotes I verified verbatim in the corpus - same menu and modifier logic, and unattended EMV through a paired Lightspeed Payments terminal - so the partial is not shortfalling every conjunct. The accessibility conjunct fails. The named shortfall is widened to include market availability on the same evidence as order-capture-kiosk-first-party: the kiosk is an O-Series app, O-Series is the AU/NZ Kounta line, and the Lightspeed Kiosk product page exists only at /au/ while the US, UK, CA and NZ paths return a 404 byte-identical to a fabricated-path control. Differentiator weight, but partial, so the A/B grade floor for a yes is not engaged; grade B is the vendor help centre. |
| order-capture-voice-ai | unknown (F) — never examined | resolve-to-no | Resolved from unknown to no, upheld on both limbs after I verified the precedent the first pass leaned on. The odoo-pos precedent does exist in this corpus and says what was claimed: that record's order-capture-voice-ai note reads in part 'developer/reference/external_api.html is a generic ORM XML-RPC/JSON-RPC surface, not a voice-AI partner program - a third party could write pos.order over it, but Odoo publishes no programme for doing so', and the same note supplies the ruling on the series question below - 'in NEITHER edition is this order capture, which is why this is a no and not an edition-gated partial'. Lightspeed's Developer Application page is the same shape. Limb one is settled by an enumerated AI portfolio in both series, none of it voice or order capture. I re-ran every control in a script written to disk with passing positive controls, and I closed a 65-page hole in the partner census before relying on its zeros. Bound limit disclosed in the note: the K-Series Integration Hub is a second, login-gated partner directory, but it cannot contain a published partner PROGRAMME, which is what limb two asks for. |
| digital-voice-ai-phone | unknown (F) — never examined | resolve-to-no | Resolved from unknown to no. I moved the citation off the O-Series integrations table and onto the Voicee partner page, because that page is what actually carries the proposition: the only telephony partner Lightspeed names anywhere describes a caller-ID lookup of a PENDING order plus a staff alert, which is the opposite of injecting a completed order. I re-fetched it at 200 on 2026-09-15 and quote it verbatim. I closed the 65-page hole in the partner census before relying on its zeros, and the completed 450-page census still returns tokenised voice 0, IVR 0, telephony 0 and caller 1. The honest bound limit is stated in the note: the K-Series Integration Hub is a second, in-product, login-gated partner directory described as holding 'hundreds of integrations', so no public-directory zero is a statement about its contents. I still uphold no rather than dropping to unknown, because a partner that answered inbound calls and wrote orders into the POS is a marketed capability, and Lightspeed documents its ordering channels - Google, Uber Direct, Deliverect - in detail while naming no telephony ordering partner in either help centre or on any of its 450 partner pages. |
| digital-apple-business-connect | unknown (F) — never examined | resolve-to-no | Resolved from unknown to no. On the taxonomy wording: the claim reads 'Supports Apple Business Connect ordering placement', and this corpus reads that uniformly as VENDOR provisioning, not as whether an operator could do it by hand. gotab's note says so in terms - 'an operator self-registering an ABC action pointing at their GoTab menu URL would not make this a vendor capability' - and speedline's makes the same point; the discriminating test used across all twenty existing `no` rows is that the vendor built and documented the Google analogue and nothing for Apple, which is exactly Lightspeed's position. I verified the enumeration independently from sections.json rather than from prose: the K-Series section 'Integrations for Order Anywhere' contains exactly two articles, Google integrations for Order Anywhere and Setting up Uber Direct for Order Anywhere. I also confirmed the first pass's disclosure that its single 'Order Food' hit was a false positive welded by its own regex, and I closed the 65-page partner-census hole; Uberall, one of the 65 that had been unread, is a listings-management partner but its Lightspeed page names no map platform and no ordering action, and the directory's single Apple Maps hit is Shipday's driver-navigation blurb. Niche weight, so the differentiator grade floor is not in play. |
| reporting-history-retention | unknown (F) — never examined | resolve-to-no | Resolved from unknown to no, with the citation moved and the evidence materially strengthened and corrected. The first pass mis-listed which nine reports carry the 28-day default (it named Checks, Turn time, Discounts and Server scorecard; the actual nine are Most Popular, Repeat Customer Favorites, Net sales, Gross sales, Sales > Covers, Card sales, Time of day, Day of week and New vs. repeat) and it attributed the hard cap to one report when eight carry it verbatim: 'you cannot select a date range longer than three months'. That is an enumerated published ceiling, not an absence, which is why I uphold no rather than dropping to unknown - this verdict does not rest on a zero. I re-ran the fixpoint and found two gated articles the first pass missed, BOTH of them reporting articles, and I disclose them: they are the reason a reader should treat this row as falsifiable. I weighed dropping to unknown on that ground and did not, because the held twin of one of them, Device Reports (NOAM), documents no window at all, and because every published window in a complete publisher manifest is shorter than 24 months. I also corrected the legal premise: the Service Agreement has no retention term, but the Data Processing Agreement does have a section 8 'Retention and deletion', and it is qualitative and about Personal Data, not a reporting window. |
| hardware-usable-after-churn | unknown (F) — never examined | resolve-to-partial | Resolved from unknown to partial, and the first pass's central premise corrected. It stated that 'The Lightspeed Service Agreement's termination clauses address only account deactivation and deletion of Customer Content'. That is false: the agreement has a section 3 headed Hardware with five subsections, and I read all of it. Section 3.1 is an outright purchase at a purchase price with no lease, no title retention, no return-on-termination obligation and no reserved remote-disable right anywhere in the agreement; section 3.2's warranty carve-out '(v) if used with products or services not provided or licensed by Lightspeed' presupposes that the customer may run the device with non-Lightspeed products and voids only the 30-day warranty; and section 3.5 imposes a genuine 24-month hardware clawback on discounted or free units. That matters because as written the first pass's shortfall 1 - 'Lightspeed publishes NO post-cancellation hardware statement anywhere' - negated the entire claim and made the partial self-refuting. It no longer does: the surrounding commercial facts are published and only the conclusion is not, which is the same shape as the ncr-voyix-aloha row in this corpus. Grade B as vendor legal text. |
| hardware-callerid-integration | unknown (F) — never examined | resolve-to-partial | Resolved from unknown to partial, citation moved and the shortfall widened. The partial is not self-refuting: a telephony integration with caller identification and a POS-side order lookup genuinely exists and is vendor-named, so one conjunct of the claim is met; what fails is the depth of the pop and the availability. I moved the url from the O-Series integrations table to the Voicee partner page because that is the document that actually describes the behaviour, and I re-fetched it at 200 on 2026-09-15. I verified that Voicee really is in the Marketing row of the O-Series supported-integrations table, and note for accuracy that its own partner page files it under 'Category: Features / Tools', not Marketing. The shortfall is widened to market availability on evidence I established myself: O-Series is the Kounta AU/NZ line, and Voicee's own compatibility line and Australian phone number match. Niche weight, so the differentiator grade floor is not engaged. |
| commercial-wcag-kiosk-accessibility | unknown (F) — never examined | resolve-to-no | Resolved from unknown to no, but the first pass's load-bearing argument is WITHDRAWN. It claimed the compliance-reports article is a CLOSED enumeration of the Security Trust Center Resources tab. It is not. I read the whole article: its own scope line is 'This article provides an overview of Lightspeed's compliance reports across Retail, Hospitality, and Golf product Series'; the bullets are introduced by 'You can click the tabs at the top of the Security Trust Center for more information on:'; and the article itself says 'Some documents within the Resources section are access-restricted and not publicly viewable or downloadable' and tells the reader to 'use the tabs or search bar to locate a specific resource'. An overview of a partly non-public set cannot close it, and I also could not read the Trust Center itself - trust.lightspeedhq.com is a Vanta single-page app whose every path, including a deliberately nonsensical control path, returns the same 6,766-byte shell, so it is NOT bounded and I say so in the note. The verdict survives on better evidence that I gathered instead: the published Legal index at /legal/ is a closed list of fourteen documents with no accessibility document; /accessibility/ 404s while /legal/accessibility/ returns a 200 that is a page-builder shell carrying only navigation chrome, 4,015 stripped characters against 4,099 for a 404, with no body text at all; WCAG, VPAT, 'Section 508' and tokenised ADA are all zero across a corpus that is a complete publisher manifest; there is no accessibility clause in the Service Agreement, the DPA or the Privacy Policy; and the claim's second conjunct, a documented tactile or audio non-visual kiosk access mode, is affirmatively absent from the kiosk article's own enumerated configuration surface. A targeted web search for a Lightspeed VPAT or ACR returned nothing first-party; the only Lightspeed-and-accessibility result is a third-party overlay vendor selling a WCAG widget for Lightspeed, which points the same way. |
Sources
Every URL this record cites. 167 in total.
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804656709-Creating-and-managing-floor-plans-and-tables
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/360051089493-Check-splitting
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050328374-About-ordering
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4408089985179-Creating-and-managing-bar-tabs
- https://apps.apple.com/us/app/lightspeed-restaurant-pos-k/id1486190847
- https://www.lightspeedhq.com/pos/restaurant/quick-service-restaurant-pos/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804647349-About-menus-and-items
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4402274951323-About-price-lists
- https://api-docs.lsk.lightspeed.app/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407511552155-Creating-and-managing-recipes
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/25208938481691-Setting-up-the-Deliverect-integration
- https://www.lightspeedhq.com/payments/
- https://www.lightspeedhq.com/pos/restaurant/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities
- https://www.lightspeedhq.com/pos/restaurant/payroll/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/6339161622427-About-gift-cards-2-0
- https://www.merchantmaverick.com/reviews/lightspeed-restaurant-review/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/36914000260891-Setting-up-and-using-the-UEAT-integration
- https://www.lightspeedhq.com/pos/restaurant-k-series/integrations/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4686224687259-Online-ordering
- https://www.lightspeedhq.com/pos/restaurant/pricing/
- https://trust.lightspeedhq.com/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/10804963031323-Selling-gift-cards-2-0-online
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407509542043-Stock-management-Inventory
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407517428891-About-Inventory
- https://status.lightspeedhq.com/
- https://api-portal.lsk.lightspeed.app/quick-start/intro
- https://api-portal.lsk.lightspeed.app/quick-start/authentication/authorization-overview
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/40834565217691-About-the-Integration-Hub
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/16154347413275-Network-requirements-for-Lightspeed-Restaurant
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260805671909-Launching-Lightspeed-Restaurant-checklist
- https://www.lightspeedhq.com/legal/lightspeed-service-agreement/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/5028210082715-Standalone-payments
- https://k-series-support.lightspeedhq.com/hc/en-us/sections/34839005050651-Loyalty
- https://www.lightspeedhq.com/pos/restaurant/pricing/
- https://www.lightspeedhq.com/payments/
- https://api-portal.lsk.lightspeed.app/quick-start/intro
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/22168531609499-Setting-up-Kitchen-Display-System-2-0
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804658689-Managing-production-centers
- https://k-series-support.lightspeedhq.com/hc/en-us/sections/34839005050651-Loyalty
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/16154347413275-Network-requirements-for-Lightspeed-Restaurant
- https://www.lightspeedhq.com/news/lightspeed-commerce-divests-upserve-u-s-hospitality-product-line-to-skyview-equity-transaction-sharpens-focus-on-core-growth-engines-of-retail-in-north-america-and-hospitality-in-europe/
- https://www.lightspeedhq.com/news/lightspeed-announces-fourth-quarter-and-full-year-2026-financial-results-and-provides-outlook-for-fiscal-2027/
- https://www.lightspeedhq.com/blog/kounta-joins-lightspeed/
- https://www.lightspeedhq.com/news/lightspeed-pos-inc-announces-the-acquisition-of-gastrofix/
- https://www.lightspeedhq.com/blog/lightspeed-acquires-upserve/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/5328889461378
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260800124209-Supported-hardware
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657389-About-order-profiles
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4402267214363-Linking-order-profiles-to-price-lists
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804579349-Managing-users-and-floor-plans
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/10071706424347-Tap-to-Pay-on-iPhone-with-Lightspeed-Payments
- https://www.lightspeedhq.com/pos/restaurant/payments/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4402294260251-Managing-chargebacks-with-Lightspeed-Payments
- not refetchable
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803517810-About-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803553189-Placing-orders-using-Order-Anywhere
- https://www.lightspeedhq.com/au/pos/restaurant/kiosk/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050309174-Clocking-in-and-out
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403208456603-Understanding-the-Dashboard-page
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/42676619412251-Understanding-the-Back-Office-Lightspeed-AI-agent
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4755505361947-Sharing-menus-with-business-locations
- https://k-series-support.lightspeedhq.com/hc/en-us/categories/8348673720987-Reports
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/23973504428059-Navigating-business-locations
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/360056758213-Contact-us
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/43642296058139-Setting-up-multi-factor-authentication
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803518310-Setting-up-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/29496064755099-About-the-Lightspeed-Pulse-App
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/51623634913051-Understanding-modifiers-and-modifier-groups
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804656369-Adding-modifiers
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/10724827631259-Setting-up-and-using-Item-availability
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/12625085075995-Surcharging-with-Lightspeed-Payments
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/15214224728987-Lightspeed-Payments-FAQ
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804594730-Managing-POS-user-groups
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403189318043-Cancellations-and-Corrections-report
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407098296091-Managing-Order-Anywhere-service-profiles
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/6732200120091-Managing-customer-accounts-in-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804607010-Managing-printing-profiles
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804658549-About-printing-profiles
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403156004763-Product-Mix-Report
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403197629595-Invoices-report
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804658149-Managing-POS-devices
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/18810450475547-Filtering-Reports
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/29760563418907-Processing-service-charges
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/15214224728987-Lightspeed-Payments-FAQ
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/5028210082715-Standalone-payments
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/18140638499355-Troubleshooting-Lightspeed-Payments-for-Restaurant-POS
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804607010-Managing-printing-profiles
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804606770-Printing-FAQ
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/11395178539931-Setting-up-and-using-Group-Ordering
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/39777750001051-Google-integrations-for-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/7340976689051-Guest-book
- https://k-series-support.lightspeedhq.com/hc/en-us/sections/34839005050651-Loyalty
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050309174-Clocking-in-and-out
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407517612699-Stock-levels
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/6669636140443-About-Items-Inventory
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407511552155-Creating-and-managing-recipes
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4415116773403-Handling-tips-and-gratuities
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/22168531609499-Setting-up-Kitchen-Display-System-2-0
- https://apps.apple.com/us/app/lightspeed-restaurant-pos-k/id1486190847
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403941107099-Creating-customer-invoices
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/51623634913051-Understanding-modifiers-and-modifier-groups
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804656569-Creating-combos
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/50574509323291-Understanding-Menu-upsells-in-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803521850-Enabling-payments-for-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403941259291-Managing-customer-invoices-in-the-Back-Office
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/23267765915547-Fulfilling-orders-from-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/25724049883675-Setting-up-the-Uber-Eats-integration
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804656349-About-production-instructions
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4413369711771-About-Lightspeed-Order-Display-Screen
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657089-Understanding-discounts
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4403156122651-KDS-Statistics
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/34339315446171-What-s-new-Self-delivery-for-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803546769-Creating-Order-Anywhere-service-profiles
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050436394-Managing-cash-drawer-operations
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/38418918961819-Understanding-the-Online-orders-report
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/5780735561883-Viewing-orders-in-the-Lightspeed-Delivery-Dashboard
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260803553189-Placing-orders-using-Order-Anywhere
- https://www.lightspeedhq.com/integrations/?product=restaurant
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/6339630673435-Gift-cards-2-0-FAQ
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/41912627014939-Creating-promotions-with-Order-Anywhere
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657189-Importing-or-exporting-customer-data
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/24012819812891-Setting-up-the-Marsello-integration
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/7341353071131-Campaigns
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/34338126103195-What-s-new-Loyalty-cards-in-Apple-Wallet
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/40994945471515-Understanding-the-Staff-Performance-report
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/20537741099419-Discrepancy-reports
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407510354715-Performing-stock-counts
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/22675539589787-Setting-up-the-MarketMan-integration
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/11207355170203-Purchase-Reports
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/7116014889499-Wastage
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804657449-Understanding-void-reasons
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/360050328874-About-POS-reports
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/12285092786203-Automated-reporting-with-Lightspeed-Payments
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4406100835227-Adding-rules
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/43733543286683-Understanding-Gift-cards-statistics
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/27536544139547-Network-optimization-checklist
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/53288894613787-Troubleshooting-network-issues
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804513230-Introduction-to-hardware
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/23340222300059-About-data-privacy-and-security
- https://www.lightspeedhq.com/pos/restaurant/multilocation-restaurant-pos/
- https://www.lightspeedhq.com/integrations/?product=restaurant
- https://www.marketman.com/page/restaurant-invoice-management-system
- https://store.lightspeedhq.com/
- https://www.lightspeedhq.com/au/integrations/voicee/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/42198624229147-Setting-up-Lightspeed-Tasks
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/10275376724507-Preparing-your-site-for-installation
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/28477493132571-Receiving-Instant-Payouts-with-Lightspeed-Payments
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4405144744347-Getting-paid-with-Lightspeed-Payments
- https://k-series-support.lightspeedhq.com/api/v2/help_center/en-us/articles.json
- https://api-docs.lsk.lightspeed.app/source.json
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/53028167251867-Offline-POS-functionality
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/22708154090267-Using-the-Kitchen-Display-System-2-0
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/47746434645275-What-s-new-March-2026-Table-pacing-digital-checklists-reservations-and-more
- https://www.lightspeedhq.com/pos/restaurant/order-anywhere/
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804605810-Managing-customers-in-the-Back-Office
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/1260804594690-Managing-POS-users
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4407569259547-Creating-purchase-orders
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/19537081005467-Setting-up-the-Deputy-integration
- https://k-series-support.lightspeedhq.com/hc/articles/53028167251867
- https://k-series-support.lightspeedhq.com/hc/articles/23973504428059
- https://o-series-support.lightspeedhq.com/hc/en-us/articles/45638355445275-Setting-up-Lightspeed-Kiosk
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/4404650173467-Searching-for-certain-punch-cards
- https://k-series-support.lightspeedhq.com/hc/en-us/articles/26397623938971-Setting-up-the-Dirmeier-integration