Lavu

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

Vendor claims 'Easily manage tables, menus, and more'; graphical editor depth, multiple saved layouts and server-section assignment are not documented publicly. https://lavu.com/compare-lavu/ · retrieved 2026-08-01

Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.

order-capture-seat-level

Documented help-center article "POS - Active Seat and Course" — seat assignment of items is a shipped POS function, not an inference. https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-01 adversarially verified

Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.

order-capture-coursing-hold-fire

Two documented articles: "POS - Active Seat and Course" and "Hold & Fire". https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-01 adversarially verified

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

Both halves are documented: "POS - Merging Orders" and "POS Video - Splitting Orders". Reviewer complaints about UX difficulty are a usability finding, not a capability gap, and should not have held the score at partial. https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-01 adversarially verified

Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator

order-capture-bar-tab-preauth

Card pre-auth tabs exist — help-centre articles "Pre-Authorization Flow on POS App" and "POS - Change Service Types (Quick Serve, Tables, and Tabs)". Shortfall: the claim additionally requires a configurable auth amount, incremental re-auth as the tab grows, and end-of-day auto-close of stale tabs; none of the three is documented. https://support.lavu.com/en/knowledge/lavu-pos · 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

Transfer is documented: tap the Order #/table/tab header > Assigned Server > select the receiving server > Confirm, restrictable via Advanced Location Settings; item movement between orders has its own 'Disable inter-order item transfers' switch. The Action Log report records front-end activity filterable by employee and device and exports to CSV, but no doc states that a transfer event is logged naming both employees. https://support.lavu.com/en/knowledge/manager-handbook-transfer-orders · retrieved 2026-08-05

Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.

order-capture-native-handheld

The Lavu POS is a native iOS app, not a mirrored session: the KB carries iPhone/iPod-specific interface settings ("Order pad font (iPhone/iPod)", "Return to order pad after selecting an item on your iPhones/iPods") and an explicit device-capability difference ("Reordering is only available on iPads and this feature is not available on iPhones or iPods"). Sending to kitchen is in-app ("Allow order resend ... the option of resending items to the kitchen"). Card payment is taken on the same device: the VP3300 "connects to your POS through Bluetooth, and is capable of swiped transactions, EMV chip inserts, tap to pay programs like Apple Pay, and manual entry directly through the POS", paired from Settings > Card Reader Settings > VP3300, and Lavu sells a carried configuration (iPad mini + VAULT GoWork Pro case + Adyen NYC1 reader) as its Wi-Fi Handheld Bundle. https://support.lavu.com/en/knowledge/how-to-connect-your-vp3300-card-reader-to-your-lavu-pos · retrieved 2026-08-09 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

Order entry offline is documented at grade B — Lavu’s "Crash Kit 101" lists "Conduct cash transactions", "Open the cash drawer", "Add food and drink to open orders", "Start new orders", "Send orders to the kitchen" and "Print checks" as working without internet. Shortfall: the claim also requires the vendor to publish what does and does not work offline, and Lavu’s two first-party sources conflict — the marketing page says "Every POS function works locally — orders, payments, modifiers, kitchen tickets", while Crash Kit 101 says credit and gift card transactions require active internet to validate card details. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-02 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

Lavu documents two QR surfaces and neither writes to an open POS check. Up N' Go prints a per-order payment QR on the check and the article states the codes "are not meant to show your customer's your menu", referring menu QR to MenuDrive. MenuDrive QR ordering requires "an additional location added to your account... used exclusively for your customers to place orders through your QR codes" because its required settings (dine-in only, ASAP only, specific prep times) "may conflict with your already established online storefront"; those orders arrive as new MenuDrive orders through an order-receiving method - "Email and text notifications, Order Dashboard, IP Printer, Lavu POS integration" - carrying the table/seat on the kitchen ticket, not as items appended to a server-entered check. https://support.lavu.com/en/knowledge/menu-drive-qr-codes · retrieved 2026-08-08

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

'Self-Ordering Kiosks' marketed and 'Kiosk' is a monitored component on the public status page; shared menu tree and ADA conformance undocumented. https://lavu.com/contactless-payments-ordering/ · retrieved 2026-08-01

Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.

order-capture-drive-thru

Positive absence across every first-party surface, with one caveat recorded honestly: the Order Types article's default list is illustrative rather than exhaustive ('Your account comes with default Order Types LIKE Dine In, Pickup, and Carry Out'), so the weight does not rest on it. What it does establish is the shape of the model - an order type is a label carrying a tax-exemption flag, attached to one of three service layouts enumerated as 'Quick Serve, Tables, and Tabs' - which has no lane, order-point, pay-window or pickup-window entity to sequence against and no pull-forward or parking-spot assignment. Against that, 'drive-thru' occurs zero times across the complete 249-URL help centre (its sitemap and its seven category pages agree exactly), zero times in the 4,844-URL first-party sitemap census, and Lavu's 43-page site carries segment pages for fine dining, food trucks, international and multi-location but none for QSR or drive-thru. https://support.lavu.com/en/knowledge/order-types · retrieved 2026-09-04 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

Follows from the absence of the drive-thru flow itself: with no order-point or window separation in the Order Types surface there are no segment boundaries to time. The only order timing Lavu documents is the KDS per-tile order timer and its colour-change duration thresholds (Lavu KDS - Settings, Functions and Features), which is ticket age on one screen rather than order/total/window segments tied to individual cars, and the enumerated Reports catalogue contains no speed-of-service report. https://support.lavu.com/en/knowledge/order-types · retrieved 2026-09-04 adversarially verified

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

326th: MOVED unknown -> no. BOTH LIMBS OF THE CLAIM FAIL AGAINST NEW VENDOR-AUTHORED SURFACES. (1) First-party agent: Lavu's own AI capability matrix on https://lavu.com/2026-restaurant-pos-ai-capabilities-report/ marks 'AI-powered voice phone ordering' as '✗ No' in the 'Lavu (Marty)' column (raw <td data-label="Lavu (Marty)" class="no">, so the attribution is per-cell, not a stripped-table artefact), and the Marty rows it DOES claim are analytic - outside payroll/scheduling connections, overnight analysis, theft and void-pattern detection, 'Chat AI (natural language Q&A)' - with no order-injection surface. (2) Partner programme: lavu.com/integrations/ (fetched today, 182,762 bytes of page content via wp-json) is a closed partner enumeration of 23 named integrations in five categories - Inventory (Bar-i, Digital Pour, Marketman, CheddarSuite), Payments & Ordering (Up'n Go, CheckPlease), Loyalty (OpenTable, LoyaltyMatch, Pepper), Accounting & Payroll (Restaurant365, Shogo, Dolce, QuickBooks, Xero, Davo) and Online Ordering & Delivery (Otter, Chowly, DoorDash, Grubhub, Uber Eats, Flipdish, Checkmate, Open Dining). No voice-AI partner appears, and there is no certification or partner-programme page for one. Controls over the 11.5 MB corpus described on digital-voice-ai-phone: IVR 0, 'drive through' 0; 'drive-thru' 48 tokenised and every one is blog labour-cost copy about timers and staffing, never a Lavu drive-thru ordering product. Retrieved 2026-09-18. https://lavu.com/2026-restaurant-pos-ai-capabilities-report/ · retrieved 2026-09-18 adversarially verified

Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator

order-capture-throttling

Positive evidence of the opposite mechanism. MenuDrive's capacity control is a single static Preparation Time per fulfilment type, and the article's whole worked example is that the constant is subtracted from the closing time to compute the last orderable minute: a 30-minute prep time and a 9 p.m. close block an 8:35 p.m. order and quote 8:55 for an 8:25 order. There are no per-slot capacity limits, no order-count ceilings, and the quoted time never moves with kitchen load; the documented remedy for wanting later orders is to widen the pickup/delivery hours, not to throttle. https://support.lavu.com/en/knowledge/menu-drive-order-types-and-prep-time · retrieved 2026-09-04 adversarially verified

Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.

order-capture-scheduled-orders

Future-dated orders exist on the MenuDrive digital channel: the storefront checkout carries an "Order Pickup Time (ASAP/Advanced)" selector, and the Item 86 Count article separately distinguishes "ASAP orders" from "In Advance orders". Shortfalls: the only timing control documented is MenuDrive prep time, which sets the last-order cutoff ("Whatever is set for prep time is subtracted from your closing time making the last available time your customer can place an order") rather than a per-channel lead time; and no article states whether a scheduled order is injected into the make queue at a computed fire time or transmitted on receipt — the fire-time half of the claim is undocumented. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-03

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

order-capture-catering

Deposit and balance-due pieces exist as generic POS features: items with 'Allow Deposits' enabled take a partial payment at checkout and the order is flagged 'Underpaid' in reports 'so you know your customer still has an amount due on their order'; MenuDrive supports Advance Orders and per-item minimums pitched at 'catering menus where there is a 5 person minimum'. Shortfall: no distinct catering queue, no quotes, and no delivery/event schedule are documented. https://support.lavu.com/en/knowledge/item-deposits · 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

Positive absence by architecture enumeration rather than by settings silence. The DSP Integration article declares its own contents - Store Onboarding, Menu Export, Order Ingestion, Limitations - and gives an explicit inner process flow for each: for onboarding and for menu sync, MenuDrive calls Lavu DSP, Lavu DSP calls the DoorDash API, and the confirmation returns; for orders, the flow terminates at ingestion, 'the final step in DSP integration'. There is no fourth flow carrying order state outward. The companion article's settings surface corroborates it: Connect/Onboard, Sync Menu, automatic out-of-stock removal, dual-pricing percentage, temporary closures and special store hours are the whole of what the integration exposes, and none of them is readiness. https://support.lavu.com/en/knowledge/dsp-integration-delivery-service-provider-integration · retrieved 2026-09-04 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

All three limbs are documented. Reason codes: 'Lavu POS - Voiding Orders & Items' - 'Depending on your settings, you may be prompted to enter a reason for voiding'; 'Creating Discounts in Lavu' has a per-discount 'Prompt for a reason' setting. Role gating: the same discount editor has an 'Access Level' field ('For manager discounts or entire meal comps, we recommend setting this to at least level 2'), 'Lavu Access Levels' puts voids, discounts and refunds at Level 2, and 'Advanced Location Settings - Order Options' sets the 'Access level required (0, 1, 2, 3, or 4)... to edit and remove saved items, and to edit and remove sent items'. Exception reporting: the Voided Items and Voided Orders reports list every void with order id, cashier and price and export to csv/xls/txt, and the void reason is retrievable per order via the order's View action log. https://support.lavu.com/en/knowledge/lavu-pos-voiding-orders-and-items · retrieved 2026-08-08

Supports modifier groups nested at least three levels deep, each level with independent min/max selection counts and a forced-selection (required) flag.

menu-pricing-nested-modifiers

Nesting and min/max both exist but not at the depth the claim asks for. MenuDrive modifier groups take a type (Checkbox, Radio, Dropdown, Quantity, Toppings Matrix) plus 'Min and Max settings, which determine how many or how few options a customer must select', and each option carries a 'Nested Modifier' toggle that 'allows you to attach another modifier group to that specific option' - one documented additional level. Lavu POS reaches the same one level through Detours ('Detours cannot be used on Checklist Forced Modifiers'), and its forced-modifier lists are typed Choice or Checklist with no min/max count fields documented anywhere. Shortfall: three-level depth is documented nowhere in either product, and on the POS side there are no independent min/max selection counts - only the Choice/Checklist type and the forced-vs-optional distinction. https://support.lavu.com/en/knowledge/menu-builder-page · retrieved 2026-08-08

A single modifier can carry different prices depending on the parent item and the selected size, configured as a matrix rather than by duplicating the modifier.

menu-pricing-modifier-price-by-parent-size

330th: MOVED unknown -> no/B. THE 328th FOUND THE FIELD-LEVEL ANSWER ON A RETIRED COPY OF THE DOCS AND HELD IT FOR THAT REASON; THE SAME RECORD IS ENUMERATED ON THE CURRENT HELP CENTRE, IN THE ARTICLES' OWN SCREENSHOTS, WHICH NO PASS HAD OPENED AS IMAGES. (1) LAVU POS modifier record, from 'Basic Menu Building in Lavu' (current, support.lavu.com/basic-menu-building-in-lavu): the forced-modifier list editor screenshot https://support.lavu.com/hs-fs/hubfs/basic_menu11.png (fetched at full resolution, read as an image) shows one row per choice with the columns ModifierID | name | Price | Default Chain Group | Ingredients | Nutrition | Select Happy Hours | Detour | image | X, and the list header carries only 'choice/Choose 1/Chain Group'. The optional-modifier editor https://support.lavu.com/hs-fs/hubfs/basic_menu14.png is the same table (911 Bread $0.00 ... 912 Patty $2.00, 920 Bacon $1.00, 921 Fried Egg $1.50). ONE price cell per modifier, no parent column, no size column, no second price. The article's own attach rule makes duplication the only route: 'if you add a modifier to the category level, and then attach another modifier to a specific menu item, that item will only read from the modifier you attached to it'. (2) SIZE IS NOT AN AXIS IN THE POS AT ALL: 'size' 16 / 'sizes' 15 tokenised over the 245-article current census and every hit is a MenuDrive category size or an image size; 'Using Pizza Creator' (current) builds size as a plain choice forced-modifier list ('I have created some generic options for size, crust, and toppings') and the creator's complete per-section settings list is Name, Forced Mods, Page, Display Order, Partial Serving Price - the only price scaling is 'Partial Serving Price ... The default is 0.5 which will cut the price of your topping in half', a half/whole factor, not a per-size price. (3) MENUDRIVE, which does have sizes, duplicates rather than matrixes: 'Menu Drive - Menu Builder Page' says 'you will need to add a price to each size in your selected categories. Each size will also have its own section for attaching modifiers. That way, different sizes can have different modifiers attached to it', and its modifier-option record screenshot https://support.lavu.com/hs-fs/hubfs/md_menu12.jpeg has exactly one money field (Name, Main POS ID, Description, Nested Modifiers, Price $0.00, 'Display this option on your storefront'); the Toppings Matrix 'Advanced Settings' screenshot https://support.lavu.com/hs-fs/hubfs/md_menu14.jpeg is Allow extra ('A price for extra will be equal to a modifier price multiplied by: 2'), 'Included in the item price', 'Show prices next to options' - a multiplier on the one price, again not a per-parent/per-size grid. BOUND: the 245-article support.lavu.com census (3,150,753 chars, every article in the sitemap, re-derived this pass) plus the live legacy data dictionary admin.poslavu.com/cp/areas/api_doc.html, whose menu_items/menu_categories rows carry only modifier_list_id and forced_modifier_group_id and which has no join table that could hold a price per (modifier, parent, size) triple. CONTROLS, tokenised and case-insensitive over the census: 'price level' 0, 'price levels' 0, 'multiple prices' 0, 'price by size' 0, upcharge 0, 'modifier price' 1 (the DSP article, about what DoorDash tickets now display). POISON: 'matrix' scores 7 and NONE is a price matrix - all 7 are the MenuDrive modifier STYLE 'Toppings Matrix' / 'Pizza Matrix' / 'Custom Topping Matrix', i.e. the half/whole placement grid; a reader grepping 'matrix' on this vendor will read 7 hits as a hit on this claim. Retrieved 2026-09-18. https://support.lavu.com/menu-builder-page · retrieved 2026-09-18 adversarially verified

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

menu-pricing-fractional-placement

Pizza Creator "automatically comes equipped with certain modifications commonly used by pizza restaurants" — "you will have the options for half toppings, light, and extra automatically built in" — and the Partial Serving Price fraction (default 0.5) prices a half topping independently. Halves only; quarters and thirds are not documented. https://support.lavu.com/en/knowledge/using-pizza-creator · retrieved 2026-08-02 adversarially verified

The half-and-half pricing rule is operator-configurable among at least two of: charge the higher-priced half, average the halves, or charge each topping at a fraction of full price. differentiator

menu-pricing-half-and-half-rule

One pricing lever only. Pizza Creator exposes "Partial Serving Price ... The default is 0.5 which will cut the price of your topping in half" — the fraction-of-full-price rule. The claim requires the rule be operator-configurable among at least two of {charge the higher half, average the halves, fraction of full}; charge-higher-half and average-the-halves are absent, and how the pizza base price is derived when two halves differ is undocumented. Verification could not corroborate a "1st Half / Whole / 2nd Half" matrix on the cited page. https://support.lavu.com/en/knowledge/using-pizza-creator · retrieved 2026-08-02 adversarially verified

Supports modifier quantity tiers (light / regular / extra / double) with a configurable price multiplier per tier, distinct from adding the modifier twice.

menu-pricing-topping-quantity-tiers

"light, and extra modifiers" are built into Pizza Creator's topping selection automatically. Whether extra carries an independent price multiplier is not stated. https://support.lavu.com/en/knowledge/using-pizza-creator · retrieved 2026-08-01 adversarially verified

Item base price can be defined as a grid across two variant axes (e.g. size x crust/preparation) with a per-cell price override. differentiator

menu-pricing-size-style-matrix

Price varies across both axes, but additively rather than as a per-cell grid. In MenuDrive, sizes are a property of the CATEGORY ('Sizes are applied to every item within your category') and the item carries one price per size; a second axis such as crust is a modifier group whose options each carry a single price, added on top. In Lavu POS, Pizza Creator assembles separate forced-modifier lists for size, crust and toppings and its only price mechanic is a per-section 'Partial Serving Price' fraction (default 0.5) for half toppings. Shortfall: no documented per-cell override for a given size x crust pair - the second axis is a flat up-charge on the per-size base price, so a 14-inch deep-dish cannot be priced independently of that additive result. https://support.lavu.com/en/knowledge/menu-builder-page · retrieved 2026-08-08

Items can define an included-modifier allowance (e.g. three toppings included) that automatically charges only for overage and credits or forbids substitutions per configuration. differentiator

menu-pricing-included-allowance

328th: MOVED unknown -> no, on FIELD-LEVEL ENUMERATIONS of every surface where an included-topping allowance could be configured. (a) THE MODIFIER RECORD IS ENUMERATED: the retired manual's 'Section 1.5: Forced Modifiers' (Apr 2019, in the 342-article retired corpus described on payments-surcharge-guardrails) says 'Fill out the forced modifier information:' and then lists it exhaustively - 'Title - name of the modifier; Price - cost of the modifier (Optional. Leave blank for $0.00.); Ingredients...; Nutrition...; Select Happy Hour...; Detour...; Blank Box - only available if you are using the Lavu Pizza Builder...; X - deletes the modifier'. One flat Price per modifier and nothing else. The mod LIST itself has only a Name, optional Happy Hours and a type: 'Choice - will require that one of the modifiers in the list be selected' vs 'Checklist - will not require any mods to be selected, but all mods in the list can be selected if desired'. Neither type expresses 'N included free, then charge'. 'Section 1.4: Optional Modifiers' is the same shape (Name, Price which 'can be a positive... or negative number', Ingredients). (b) THE PIZZA SURFACE IS ENUMERATED IN THE CURRENT HELP CENTRE: support.lavu.com 'Using Pizza Creator' says 'fill out the following settings' and lists exactly five - Name, Forced Mods, Page, Display Order, Partial Serving Price ('This will affect the price of your pizza toppings when a customer orders half toppings. The default is 0.5') - matching the retired 'Section 6.6: Pizza Settings' item for item. The only price arithmetic Pizza Creator applies to a topping is the partial-serving fraction. (c) THE DATA MODEL IS ENUMERATED LIVE: admin.poslavu.com/cp/areas/api_doc.html (200, 23,117 B today) lists all columns of menu_items and menu_categories; the only modifier-related columns are modifier_list_id and forced_modifier_group_id - no included-count, free-quantity or overage column exists to hold an allowance. (d) The current documented bundling mechanic is Combo Builder, and its pricing options are enumerated and are different in kind: 'You can import the menu item prices, add up charges for specific items, or have the price for the combo set as a whole' - an up-charge per option, with nothing about crediting or forbidding substitutions. TOKENISED CONTROLS: allowance 0, overage 0, 'included topping' 0, 'free topping' 0 across the 342-article retired corpus (1,065,356 chars), the current 249-article help centre, the 1,818-file CP3 source corpus and the two lavu.com agreements. POISON ALREADY PUBLISHED AND RE-CONFIRMED: a substring grep for 'overage' scores only inside 'coverage'; tokenised it is 0. HONEST LIMIT - THIS IS MY WEAKEST ROW: the modifier-record enumeration (a) is from the RETIRED manual and is corroborating, not load-bearing; the load-bearing current surfaces are (b) and (c). The MenuDrive 'Toppings Matrix - Advanced Settings' panel the 325th named as the one unresolved screen is still documented only as a screenshot, and MenuDrive is Lavu's online-ordering front end whose menu is POS-synced, so it cannot hold POS pricing logic the POS data model has no column for. Retrieved 2026-09-18. https://support.lavu.com/hc/en-us/articles/200175324-Section-1-5-Forced-Modifiers · retrieved 2026-09-18 adversarially verified

Supports combo/meal construction where components can be swapped with a price delta, and the system can automatically detect and convert eligible a-la-carte items in the cart into the combo price.

menu-pricing-combos

Combo Builder links menu items into combos with swap price deltas ('You can add an up-charge to options within the combo for special add ons like sweet potato fries in place of regular fries'), imported item prices or a set whole-combo price, per-component printer routing, mixed tax profiles, and Hold & Fire per component. Shortfall: automatic detection/conversion of eligible a-la-carte cart items into the combo price is not documented. https://support.lavu.com/en/knowledge/combo-builder · retrieved 2026-08-05

Upsell/suggestive-sell prompts can be configured per item and per channel (POS, kiosk, online), and the vendor reports attach-rate on those prompts. differentiator

menu-pricing-upsell-prompts

MenuDrive has 'Built-in upsell and add-on marketing' on the digital channel only; no per-channel configuration or attach-rate reporting documented. https://lavu.com/online-ordering/ · retrieved 2026-08-01

A single 86 action propagates automatically to POS, KDS, the vendor's own online ordering, kiosk, and connected third-party marketplaces, with a documented propagation latency.

menu-pricing-86-propagation

Cross-channel propagation is documented but conditional. Item 86 counts decrement jointly across POS and MenuDrive ("When an item is ordered on Menu Drive or Lavu POS, that number will decrease by 1"), and the DoorDash article confirms an out-of-stock POS item "will automatically be removed from the DoorDash storefront". Named shortfalls: the feature must be switched on by Lavu support and requires "Track in LavuPOS" enabled in the Location Profile; it "is only applicable for ASAP orders and not applicable for In Advance orders"; and sold-out items can still be added to a guest cart, with the alert appearing only "until they get to the Order Summary screen". No propagation latency is published. https://support.lavu.com/en/knowledge/item-86-count-tracking-in-menu-drive · retrieved 2026-08-02

Supports per-item countdown/par counts that decrement on sale and automatically 86 the item at zero, with a scheduled auto-restore. differentiator

menu-pricing-countdown-auto-86

Countdown and auto-86 are documented — "As the item is ordered, the number will decrease by 1", "When the number reaches 0, the item will be 86ed" — but the claim also requires a scheduled auto-restore, and the same article says the item "cannot be ordered until the number of servings is updated in the Control Panel menu". Shortfall: restock is a manual Control Panel edit; no nightly or scheduled reset is documented. https://support.lavu.com/en/knowledge/86-countdown-in-lavu · retrieved 2026-08-02 adversarially verified

Menus, individual items, and prices can be scheduled to activate and deactivate automatically by day and time in the location's own timezone.

menu-pricing-dayparting

Happy Hours schedule both prices and availability by time-of-day and days-of-week at menu category, item, and modifier level: price mode adds/subtracts a dollar or percentage amount or sets a specific price; availability mode marks items Available/Not Available on schedule ('a brunch menu only being available in the morning, or just on weekends'); multiple overlapping happy hours per day are supported via an Advanced Location Settings toggle. MenuDrive items additionally take specific-hours/days and date-range visibility and availability windows. https://support.lavu.com/en/knowledge/happy-hours · retrieved 2026-08-05

Supports distinct price books per channel (dine-in, pickup, delivery, kiosk, each third-party marketplace) including percentage-markup rules applied to a base price rather than manual per-item entry.

menu-pricing-channel-price-books

A percentage markup over base menu price is documented only for the DoorDash channel ('enable the feature, and enter a number for the percentage increase to your menu items' prices' under Dual Pricing, 5% recommended); MenuDrive items can hold prices independent of the POS when unlocked from sync. Shortfall: no general per-channel price books for dine-in/pickup/delivery/kiosk and no markup rules for other channels. https://support.lavu.com/en/knowledge/lavu-menu-drive-and-door-dash · retrieved 2026-08-05

Supports dual pricing / cash-discount at the item level with the card price displayed as the base price, applied consistently across POS, kiosk, and online ordering, and printed on the receipt. differentiator

menu-pricing-dual-pricing

Item- and modifier-level configuration and dual display at the POS are documented (5% increase applied per selection in the Control Panel; cashier, server and guest all see both prices). Shortfall: the claim requires consistent application across POS, kiosk and online ordering, which is never addressed, and the program is gated — "This program is currently only available in the U.S., and to Lavu Pay customers", with "CDP can only be enabled by a Lavu admin" by phone. https://support.lavu.com/en/knowledge/cash-discount-program · retrieved 2026-08-02 adversarially verified

Stores allergen flags and nutrition values per item and publishes them to online ordering and third-party menus, and can derive nutrition from linked recipe components rather than manual entry.

menu-pricing-allergen-nutrition

The words 'allergen', 'nutrition' and 'calorie' appear ZERO times in all 250 help-centre articles, and the item field surface is enumerated in three places that leave no room for them. MenuDrive item creation: 'you will need to provide a Name, a Menu, a Category, and a price for each size. Everything else is completely optional', plus photos and modifier groups; 'Menu Items - Advanced Settings' then states exactly what the advanced tier holds - 'Advanced Settings contains options for Special Notes, Visibility and Availability options, making Upsells, and Special Offer settings'. Publishing is enumerated too: the DoorDash menu export sends 'MenuGroup/Category/Item/ModifierGroup/Modifier Option' entities only. And api.lavu.com/docs/swagger.json - a grade-A schema, exhaustive as to that API - exposes GET /v1/customer/menus/ with no allergen or nutrition field. Ingredients can be linked to items for stock and cost, but no article derives nutrition from them. https://support.lavu.com/en/knowledge/menu-builder-page · retrieved 2026-08-08

Menu items and modifiers can be linked to recipes/bills of materials so that a sale depletes theoretical inventory and yields item-level theoretical food cost. differentiator

menu-pricing-recipe-linkage

Documented end to end. 'Inventory: Link Ingredients to Menu Items': 'Navigate to your menu item and look for the white box with the word Ingredients. When you click on it, you will be able to add your ingredients from the drop down menu, and designate how much of that ingredient is used in one serving of this menu item... With the ingredient attached to the menu item, whenever the item is sold, stock automatically be deducted from your inventory', with automatic 86 when stock runs out. Costing is real, not inferred: 'Inventory Settings' sets a Costing Method (Average/Periodic or FIFO) that 'will dictate how the Food and Beverage report tabulates cost of goods sold', and 'Tracking Food & Liquor Costs' states 'the cost of creating that menu item from your ingredients will be calculated against the price of the menu item, to give you a cost percentage', surfaced in End of Day Overview v2 through Food/Liquor super groups. Caveat on the claim's wording: ingredient linkage is documented at menu-item level only; no article shows ingredients attached to a modifier. https://support.lavu.com/en/knowledge/inventory-link-ingredients-to-menu-items · retrieved 2026-08-08

Pushes menus to third-party marketplaces through a certified direct integration (not scraping or a menu-management middleman) and surfaces per-item sync status and rejection errors to the operator.

menu-pricing-3p-menu-push

Direct certified push exists for DoorDash only: after a progressive sync, menu entities (MenuGroup/Category/Item/ModifierGroup/Modifier Option) 'get updated automatically from MD to DX', plus a manual Sync Menu button showing last-sync date/time; 'If the sync fails, it throws an error and asks you to try again.' Shortfalls: Uber Eats and Grubhub go through integrator middleware (Otter/Chowly/Checkmate), and no per-item sync status or per-item rejection reporting is documented. https://support.lavu.com/en/knowledge/dsp-integration-delivery-service-provider-integration · retrieved 2026-08-05

Supports rule-based dynamic pricing where item price varies automatically by time, demand, or channel, with configurable floor/ceiling guardrails.

menu-pricing-dynamic-pricing

Happy Hours is a genuine rule engine: each rule carries a name, a time window, the days of the week it runs, and an effect that can 'add to your item's price', 'subtract from your item's price' or 'set your item to a specific price', by dollar amount or by percentage; rules are applied per menu category, per item and directly to forced and optional modifiers, several can apply at once, and overlapping same-day rules are permitted once 'Disable Multiple Happy Hours per Day' is unchecked in Advanced Location Settings. A second mode marks items Available/Not Available instead. Shortfall: the only trigger is time of day and day of week - no demand-driven or per-channel variation is documented - and there is no floor/ceiling guardrail field; the article also warns that a price-changing happy hour shows 'no indicator that a happy hour is in affect' on the POS. https://support.lavu.com/en/knowledge/happy-hours · retrieved 2026-08-08

The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator

payments-processor-choice

Merchant gateway choice is documented, but only for the online-ordering half. MenuDrive's Payment Options page offers Lavu Pay (CardConnect) or Verifone - 'MenuDrive's newest payment gateway partner... now available for U.S. customers' - and the merchant supplies their OWN Verifone credentials ('You will then be asked if you have API credentials for Verifone... Click the orange Edit button to enter your credentials... make sure the credit card gateway is enabled'). Shortfall: for the iPad POS itself no third-party processor list is published - every documented reader path (VP3300, LANE 3000, NYC1, PAX, BOLT, iCT250 in Canada) runs through Lavu Pay/CardConnect, and the only non-Lavu-Pay POS mode documented is unintegrated, where 'Credit card info to ask for when integration is turned off' has staff key card type and last four by hand. https://support.lavu.com/en/knowledge/menu-drive-and-verifone · retrieved 2026-08-08

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

payments-published-rates

Lavu's own payment-processing page claims 'some of the lowest processing rates available' and 'transparent pricing' while publishing no rate; no rate appears anywhere on lavu.com. https://lavu.com/payment-processing/ · retrieved 2026-08-01

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

payments-dual-pricing

Raised from partial on verification, onto documentation. Cash Discount Program: "Your cashier, server, and your customers will see two prices. One discounted price if they pay in cash, and the other original total if they pay with a credit or debit card." Configured by applying a 5% increase to selected menu items and modifiers in the Control Panel, and the article shows a receipt with both totals printed on the check. Gating (US-only, Lavu Pay customers only, "CDP can only be enabled by a Lavu admin") is recorded on the adjacent menu-pricing and compliance cells. https://support.lavu.com/en/knowledge/cash-discount-program · retrieved 2026-08-02 adversarially verified

Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator

payments-surcharge-guardrails

328th: MOVED unknown -> no. THE MISSING PIECE WAS LAVU'S PAYMENT-SETTINGS DOCUMENTATION FOR THE LEGACY CONTROL PANEL, AND IT IS NOW ON DISK. NEW CORPUS: 342 RETIRED Zendesk articles recovered from Wayback (support.lavu.com moved to HubSpot; CDX gave 514 retired /hc/en-us/articles/ URLs, 342 fetched via /web/<ts>id_/<url> over https after the 327th's port-80 attempts failed; 1,065,356 chars; script wb2.mjs/mkhc.mjs in .cache/q328/lavu). This is a FLOOR, not a census - 172 of the 514 are still unfetched - but it is the first corpus that contains Lavu's numbered legacy Control Panel manual, including the four Credit Card Integration sections 5.1, 5.1.1, 5.1.2, 5.1.3 and 5.1.4 that document 'Settings > CC Integration' end to end ('Lavu POS allows for credit card integration via compatible Gateways... The information below can also be found by: Log in to the Lavu Control Panel. Navigate to Settings > CC Integration'). TOKENISED CONTROLS OVER THOSE 1,065,356 CHARS: surcharg 0, 'convenience fee' 0, debit 0, prepaid 0. FOUR INDEPENDENT CORPORA NOW AGREE: (1) this retired manual incl. the whole CC Integration surface; (2) the current 249-article support.lavu.com census, surcharg 0 / 'convenience fee' 0; (3) the 1,818-file CP3 Control Panel source corpus, which contains the shipped settings screens for all four processors Lavu integrates (modules/cp3-settings/card-integration/{adyen,cardconnect,freedompay,verifone}, each with Offline and Batching sub-components) and scores surcharg 0; (4) lavu.com's two live agreements (128,183 chars), surcharge 0. The ONLY card-cost-recovery mechanism Lavu documents is Dual Pricing / Cash Discount, and Lavu's own marketing positions it AGAINST surcharging rather than as an implementation of it ('Why Dual Pricing Crushes Surcharging'; comparison table 'Fee Caps: None / 3% maximum; Applies To: All payment types / Credit cards only; Pre-Registration: Not required / 30 days req', hq.lavu.com/dual-pricing-playbook-3). Lavu is a full POS, not a middleware product, and its own payment-settings documentation and shipped payment-settings code are both censused: there is no surcharging engine, hence no BIN/product-code debit exclusion, no network-cap enforcement and no per-location surcharge toggle. NOT a partial: no conjunct of the claim is satisfied. POISON: a substring grep for 'BIN' over the retired corpus returns 1 and it is an inventory Item Details field ('Item Name, Primary Vendor, 86 Count, Low Stock Alert, Category, Location, BIN, Serial Number, SKU'), a storage bin, not a bank identification number. Retrieved 2026-09-18. https://support.lavu.com/hc/en-us/articles/200569595-Section-5-1-Credit-Card-Integration-Integrated-Gateway-Information · retrieved 2026-09-18 adversarially verified

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

payments-emv-nfc

Upheld, but the dossier's source was the help-center homepage with confidence "documented", which does not meet the bar. Real evidence exists: the VP3300 article documents "triple-track MagStripe, smart card, and contactless technologies", Bluetooth connection to the POS, "EMV chip inserts, tap to pay programs like Apple Pay, and manual entry". Ingenico LANE3000 is also documented as a hard-wired option. https://support.lavu.com/en/knowledge/how-to-connect-your-vp3300-card-reader-to-your-lavu-pos · retrieved 2026-08-01 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

Lavu's product page 'Tap to Pay on iPhone' (lavu.com/tap-to-pay-on-iphone/, JSON-LD datePublished 2026-09-09T20:56:48+00:00, dateModified 2026-09-09T21:10:55+00:00, retrieved 2026-09-13; linked as 'Tap to Pay' under Payments & Pricing in the site-wide nav) describes phone-only contactless acceptance inside the Lavu app: 'No card reader to buy', 'Works with iPhone XS or later', 'The iPhone in your server's apron becomes the card reader'; flow 'Choose Tap to Pay on iPhone from the payment options at checkout'; setup 'Enable Tap to Pay on iPhone in the app's payment settings'; PIN entry 'iOS 16.0 and later'. The page is not the site's catch-all (7,236 stripped chars against the 43,934-char body a nonsense path returns on 2026-09-13). PARTIAL, shortfalls: (1) evidence is a single first-party marketing page (grade C), four days old at retrieval, with no support.lavu.com article (the help centre's tap-to-pay hits are all reader articles: VP3300, LANE 3000, NYC1) and no mention in the App Store Lavu POS v6.3 (Aug 4 2026) release notes, so shipped availability is asserted, not documented; (2) iPhone only - 'Android' occurs 0 times on the page, and Tap to Pay on iPhone does not cover the iPad that is Lavu's primary terminal ('iPad' appears only as nav labels). Differentiator claim: a yes needs grade A/B. Re-check for a help-centre article or release note after 2026-09-13. https://lavu.com/tap-to-pay-on-iphone/ · retrieved 2026-09-13 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

Tip prompt: "Lavu allows you to have customers sign and leave tips through the iPad screen at the time of sale", with configurable Quicktip buttons (percentage or amount, order, hidden options), and Tip Configuration by Device lets individual iPads prompt on screen rather than print a tip line. Splitting: the KB carries a splitting-orders walkthrough with per-check navigation. Card entry travels to the table: the VP3300 pairs over Bluetooth and does chip, contactless and Apple Pay through the POS, and Lavu's store sells a Wi-Fi Handheld Bundle and a Cellular Handheld (iPad mini + VAULT GoWork Pro case + Adyen NYC1 reader, "contactless, chip, and swipe") so "staff can take secure card payments at the table". Caveat worth stating: the reader is a separate Bluetooth/dock device rather than integrated into the tablet. https://support.lavu.com/en/knowledge/customize-the-sign-and-tip-screen · retrieved 2026-08-09 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

The mechanics are documented and work: a QR code is "specifically generated for each order, so there’s no chance of one of your customers paying for someone else’s order", and "Once the order is paid for, the order will automatically be closed on the POS." Shortfall: this is partner-delivered, not native — "Lavu’s partnership with Up N’ Go provides a way for you print QR codes on your printed checks", with enrolment through Lavu sales; Lavu ships no first-party scan-to-pay. https://support.lavu.com/en/knowledge/lavu-qr-codes-with-up-n-go · retrieved 2026-08-02 adversarially verified

Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.

payments-tip-adjust

Documented: "Editing Tips on the POS (Server Tips)", "POS - Refund a Tip", "Tip Configuration by Device", "Custom Gratuity". https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-01 adversarially verified

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

Workforce Settings documents configurable Tip Out rules (a percentage of total/cash-only/card-only tips, or of total or super-group sales, paid to one or more employee classes, split evenly or by hours worked) and Tip Pooling within a class (evenly or hours-worked over shift/daily/weekly periods), with results on each Server Summary. Shortfalls: no exportable per-employee pool-distribution ledger is documented, and Lavu Payroll requires tips to be keyed manually, 'be sure to account for... tips that are shared with other team members through tip outs or tip pooling'. https://support.lavu.com/en/knowledge/workforce-settings · retrieved 2026-08-05

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

Two offline card paths are documented: manual key-entry into the CardPointe virtual terminal, and "Store & Forward" using an iDynamo reader on the iPad, which stores card data locally and processes it once connectivity returns, described as trading verification speed for operational continuity. Shortfall: the claim requires configurable per-transaction and cumulative offline limits — no limit of any kind is published — and store-and-forward is tied to the iDynamo rather than the standard VP3300. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-02 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

OVERTURNED on the first limb. Lavu does publicly document loss allocation for offline card transactions, just not in the help centre: lavu.com/terms-of-service/ (last updated 12/01/2025) states "We may offer a feature that facilitates transacting Offline Credit Card Transactions with the Lavu Products, or your User Account. If you choose to utilize this feature you agree that we are not liable for any damages or losses from the use of this feature", provided "As Is" and at the merchant's "sole risk". That answers who bears the loss - the operator does. This is also where Lavu Crash Kit 101 was pointing when it said "Before using this feature, you will need to agree to the following terms and conditions in your Control Panel, and on the POS." Named shortfall: the second limb is still unmet - no post-reconnect report of failed offline payments appears in any documented Lavu Reports family (Sales, Cash Management, Labor, Refund Summary, V1 Reports), and the terms describe liability in the abstract rather than a reconcilable list of declines. https://lavu.com/terms-of-service/ · retrieved 2026-08-08 adversarially verified

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

Not just a Gartner/Software Advice feature-list entry — Lavu's help center has a native "Lavu Gift/Loyalty" category with a "Digital Gift Cards" article. First-party stored value is shipped. Multi-location and online-channel redemption still undocumented. https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-01 adversarially verified

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

payments-house-accounts

Positive absence by enumeration of both halves of the claim. The customer object is fully documented in Customer Management and holds identity only - name, address, phone, email and operator-defined custom fields, with a configurable signup form, an order History view, CSV Customer Import and Customer Export - and carries no balance, no credit limit and no statement or invoice run. The tender side is enumerated in The Checkout Layout Editor, where every payment button the POS can present is configured: up to two rows of four, drawn from the standard set plus 'custom payment options like gift card or check', with an Other button holding the overflow. A custom payment method is a label on a button, not an account ledger, and tabs in Lavu are an open-check service layout rather than a stored customer account. https://support.lavu.com/en/knowledge/customer-management · retrieved 2026-09-04 adversarially verified

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

Tab splitting is marketed; supported split modes, multi-tender settlement and any split-count cap are undocumented, and reviewers report the flow is very hard to use. https://lavu.com/compare-lavu/ · 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 gating is documented for three of the four action types: "Require admin PIN to void orders or checks", "Require admin PIN to void payments or refunds", "Require admin PIN to perform refunds", "Access level required to void items" and "Access level required for generic discount types", plus optional reason prompts for refunds and generic discounts; the void/refund article adds an "Access level required to perform voids and refunds from the Open/Closed Orders screen" (disabled by default). The Action Log "shows all frontend activity" including "Refund Applied", filters to "see which employees conducted refunds", and exports to .txt/.xls/.csv. Shortfalls: no documented gating for no-sales; the log records the acting employee but nothing states it captures the approving manager's identity; immutability of the log is not documented. https://support.lavu.com/en/knowledge/advanced-location-settings-checkout-options · 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

Positive evidence that the dispute surface lives outside the product. Lavu's own instruction for examining card transactions is to leave Lavu: 'Log into your CardPointe account using the link here', then Reporting > Transactions, searching by the last four digits or the auth code, 'Both of these are available in the Lavu Control Panel' - Lavu supplies the lookup keys and CardConnect holds the record. The words chargeback and dispute occur nowhere in the complete 249-article help centre, there is no open-disputes list or evidence-submission flow in the Control Panel's documented Transactions module, and the Terms and Conditions place processing entirely with the third-party gateway. https://support.lavu.com/en/knowledge/reviewing-transactions-in-cardpointe · retrieved 2026-09-04 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

A stored card exists, but only inside the online storefront. 'Menu Drive's Online Ordering Storefront' says that once a customer signs up and logs in, 'Customers can update their contact information, credit card numbers, and delivery address for faster ordering'. Shortfall: that store is scoped to the MenuDrive storefront account - nothing documents reuse of it for a phone order taken on the POS or for an in-store check; Lavu's POS-side customer object ('Customer Management') holds contact fields, custom fields and order history with no payment instrument; and neither the storefront article nor any Lavu Pay/CardPointe article states that the stored value is a token rather than a PAN. api.lavu.com/docs/swagger.json exposes no token or stored-instrument endpoint - its payment paths are create-payment-record, external-payment and payment-intent. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-08

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

payments-payout-timing

Positive evidence of non-publication in the document where funding terms would be stated. The Accepting Credit Card Payments section disclaims the role outright - 'We do not directly handle processing of credit card transactions. The Lavu Products simply facilitate transacting credit cards through integrated third-party Credit Card Gateway and Processing partners' - and puts settlement verification on the merchant: 'You are responsible for verifying that your credit card batch is settled and that all amounts are correct on a daily basis', with a seven-day window to report a discrepancy. No deposit schedule, funding window, or next-day or instant-funding option is published there, on lavu.com/payment-processing/, or in the CardPointe articles; batching is documented as a per-terminal operator action. https://lavu.com/terms-and-conditions/ · retrieved 2026-09-04 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

Verified the underlying quote, which the researcher paraphrased: "Lavu Pay is PCI-compliant, keeps data secure, accepts payments offline, and provides real 24/7 support." No AoC, no PCI DSS version, no P2PE listing, no SAQ type. Partial with confidence "claimed" is correct. https://lavu.com/payment-processing/ · retrieved 2026-08-01 adversarially verified

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

Sole evidence is marketing bullets on the KDS product page ("Route orders to the right station automatically. Set up multiple screens"). I found no KDS configuration documentation in the public help center to corroborate operator-configurable station routing rules. Claim-level marketing should not carry a "yes" on a differentiator cell. https://lavu.com/kitchen-display-system-kds/ · retrieved 2026-08-01 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

Positive absence in the vendor's own complete KDS reference, which enumerates every setting and function of the product: User Sign In, Show Date/Time, Show Table, Show Timer, Show Ticket Updates, Show Paid Status, Show Ingredients, Expanded Ticket View, Tile Display (Row x Column and Order Queue Direction), Company Logo and Item Count. There is no expo or expeditor screen type, no multi-station consolidated order view, and no all-stations-bumped completion rule - routing is one printer profile per menu category (Lavu KDS - Printer Profile) and each screen bumps independently, the only cross-item aggregation being a bumped/total item count inside a single ticket. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · retrieved 2026-09-04 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

'The Active Course feature allows course numbers to be assigned to menu items for an order, allowing each course to be sent to the kitchen separately'; at send time, 'Tap the appropriate course to send to the kitchen OR send all unsent items.' Hold & Fire alternatively holds items on a per-item timer or indefinitely for manual fire; the two modes are mutually exclusive ('You cannot use course labels if you are using Hold & Fire'). https://support.lavu.com/en/knowledge/pos-active-seat-and-course · retrieved 2026-08-05

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

330th: MOVED unknown -> no/B (the 328th proposed partial on the inventory recipe field and the merge held it; this is the other shape - both conjuncts fail against CURRENT, non-retired vendor enumerations). SECOND CONJUNCT: the current article 'Lavu KDS - Settings, Functions and Features' (support.lavu.com/lavu-kds-settings-functions-and-features, in the 245-article census) enumerates the KDS surface heading by heading - User Sign In, Show Date / Time, Show Table, Show Timer, Show Ticket Updates (appended/modified/void), Show Paid Status, Show Ingredients, Expanded Ticket View, Tile Display (Row x Column; Order Queue Direction L-R 'first in, first out' or R-L), Company Logo, Item Count - and the only timing mechanic in it is the per-tile order timer plus the colour-change interval ('Disabling the timer does not affect the order duration settings, which will trigger a color change at the designated interval(s)'). Nothing sequences or delays an item by its cook time. Lavu's own answer to finishing a table together is MANUAL: 'POS - Active Seat and Course' (current) says 'The Active Course feature allows course numbers to be assigned to menu items for an order, allowing each course to be sent to the kitchen separately ... Tap the appropriate course to send to the kitchen OR send all unsent items', and Hold & Fire is a server-selected delay ('Hold and Fire settings allow you to adjust the time intervals that can be selected when using the Hold and Fire function on the app', Advanced Location Settings - General Interface Settings) which the vendor states is mutually exclusive with courses ('You cannot use course labels if you are using Hold & Fire'). FIRST CONJUNCT: no cook time on the menu-item record - the live legacy dictionary admin.poslavu.com/cp/areas/api_doc.html lists all 30 menu_items columns with no cook/prep column, and 'cook time' scores 0 tokenised over the whole current census; the only prep/cook-time fields Lavu ships are on the INVENTORY recipe / prep-item record (cp3-inventory-new/components/PreparationTime), which the 328th merge correctly ruled is recipe metadata, not a KDS input. CONTROLS over the 245-article census (3,150,753 chars): stagger 0, staggered 0, pacing 0, 'cook time' 0, 'fire time' 0, coursing 0. POISON: 'prep time' scores 9 and every one is LOCATION-level online-ordering lead time, not a per-item cook time ('Menu Drive - Order Types and Prep Time': 'whatever is set for prep time is subtracted from your closing time making the last available time your customer can place an order'; the order dashboard 'confirm an order and sent a notification to the customer with the estimated prep time'); and in the CP3 source corpus 'pacing' scores 198 on a substring grep, all of them CSS letter-spacing (published in the 324th). Retrieved 2026-09-18. https://support.lavu.com/lavu-kds-settings-functions-and-features · retrieved 2026-09-18 adversarially verified

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

kitchen-order-throttling

The only pacing lever between digital ordering and the kitchen is MenuDrive's static Preparation Time, which fixes both the quoted ready-time and the last orderable minute and never varies with kitchen load or ticket volume. The KDS reference exposes no load threshold, no release delay and no queue hold - its Tile Display setting caps how many tickets are visible on screen (1x3 or 2x3), not how many are released - so neither release pacing nor automatic quote extension exists. https://support.lavu.com/en/knowledge/menu-drive-order-types-and-prep-time · retrieved 2026-09-04 adversarially verified

Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator

kitchen-channel-pause-propagation

86 propagation to DoorDash is automatic: 'If an item is out of stock on the POS, then the item will automatically be removed from the DoorDash storefront', working with Item-Level 86 Tracking or ingredient inventory; sold-out items also auto-block MenuDrive orders. Shortfalls: DoorDash is the only directly connected marketplace (Uber Eats/Grubhub via integrator middleware), and store pause is a manual Temporary Closure toggle in the MenuDrive control panel, not an action from POS/KDS. https://support.lavu.com/en/knowledge/lavu-menu-drive-and-door-dash · 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

The same architecture enumeration read from the KDS end: the DSP integration declares three process flows - store activation, menu export, order ingestion - each with an explicit inner call sequence, and ingestion is named 'the final step'. Nothing carries state back out. Bumping is a KDS-local action; Lavu KDS - Settings, Functions and Features documents the Bump button and the per-ticket bumped/total item count with no downstream event, so courier dispatch cannot be driven by actual readiness. https://support.lavu.com/en/knowledge/dsp-integration-delivery-service-provider-integration · retrieved 2026-09-04 adversarially verified

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

kitchen-bump-bar-hardware

KDS is driven by a tile-based touchscreen interface with bump functionality, and the certified hardware is the Epson KDS with a MicroTouch screen. Shortfall: the claim requires physical bump bars or programmable keypads in addition to touch, with documented supported models; Lavu’s equipment article lists printers, cash drawers, card readers, a scale and a tablet stand, and names no bump bar model. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · retrieved 2026-08-02 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

Positive absence by enumeration: the KDS reference lists every display mode and aggregation the screen offers, and the only count in the product is per-ticket - 'A count of bumped / total items has been added to the center of the lower margin of each order ticket'. No view aggregates outstanding quantities per item, or per modifier, across the open tickets on a station; the Tile Display setting only controls how many order tiles fit on screen. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · retrieved 2026-09-04 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

Configurable time-based color escalation is documented: 'the order duration settings... will trigger a color change at the designated interval(s) whether the order timer is enabled or not.' Shortfalls: no per-station or per-order-type target times and no audible alert are documented. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · retrieved 2026-08-05

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

Lavu's documented answer to an unavailable kitchen printer is manual, not automatic: Printer Redirects "are a way you can temporarily change which kitchen printers your menu items print from", must be enabled per order-taking device ("if you need all of your iPads to redirect, you will need to follow these steps for each individual order taking device") and manually reversed afterwards ("When you are finished using that redirect, you will need to come back to this screen to disable your redirect"). Basic Printer Setup enumerates the complete per-printer configuration — setting, name, static IP, port, type, command set, model, image capability — with no backup-printer or failover field, and the Epson "Failed to Write" article ("the iPad is unable to find your printer") prescribes restoring connectivity only. A documented manual workaround plus an enumerated settings surface lacking any backup option is positive evidence there is no automatic failover; consistent with the reliability-printer-fallback finding. https://support.lavu.com/en/knowledge/printer-redirects · 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

A KDS screen is bound to the POS over the LAN — the printer profile is created by entering "the iPad’s IP address" and port 5288 — which makes local ticket delivery architecturally plausible. Shortfall: neither the KDS documentation nor Crash Kit 101 states that KDS screens continue receiving and displaying tickets while the cloud backend is unreachable; the vendor never asserts it. https://support.lavu.com/en/knowledge/lavu-kds-printer-profile · retrieved 2026-08-02 adversarially verified

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

kitchen-item-build-screens

The Show Ingredients setting, 'in conjunction with User Sign In, permits the KDS to display a given item's ingredients in an expanded window' with quantities and the item description, via the 'i' icon beside each order item. Shortfalls: the build detail is a tap-opened window rather than on the ticket face, and User Sign In exists 'to support the KDS's premium features' priced through the sales team. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · 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 reference enumerates how modifiers render on the make line and the rendering is textual and flat: modifiers appear under their item, altered ones turn orange with a (MOD) tag, new ones carry a (NEW) tag, voids strike through, and Show Ingredients opens a list window. There is no sectioned, halved or quartered visual representation of topping placement anywhere in the display model. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · retrieved 2026-09-04 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

POS-side refire exists: the 'Allow order resend' setting enables 'resending items to the kitchen' without re-entering the order. Shortfall: KDS-side recall/unbump of a bumped ticket is not documented, and the KDS doc states that when an item is added to an already-bumped order 'the KDS will create a new order tile rather than retrieving the previously bumped order contents'. https://support.lavu.com/en/knowledge/advanced-location-settings-order-options · retrieved 2026-08-05

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

Raised from partial on verification. Lavu’s KDS settings documentation describes items modified after the ticket is displayed rendering with an orange highlight and a "(MOD)" tag on the live ticket — the claim is exactly that POS edits to an already-displayed order visually flag the changed items. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · 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

Lavu's Kiosk listing (seller Lavu Inc, v2.5, July 2024) lists 'Works with Lavu Order Monitor Screen' among its features, and status.lavu.com monitors an 'Order Status Monitor' component, so a guest-facing order-status display exists in the product line; lavu.com/kitchen-display-system-kds/ adds that the KDS can 'notify servers when orders are ready'. Shortfall: no article or listing says a KDS bump drives the monitor (the documented context is kiosk order placement), no SMS or app-push guest notification is documented anywhere, the help centre has no Order Monitor article, and whether the monitor is included or a separate purchase is unpublished. https://apps.apple.com/us/app/lavu-kiosk/id1314002834 · retrieved 2026-09-02 adversarially verified

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

kitchen-waste-logging

Waste logging with reason codes that depletes stock is documented: Waste Items requires Item Name, Waste Quantity, and Waste Reason, with preloaded reasons (Damage, Spoilage, Mismade) plus custom reasons 'to be used in the Control Panel and POS'. Shortfall: entry is from the Inventory Manage area or POS functions, not from the kitchen/KDS screen. https://support.lavu.com/en/knowledge/inventory-manage-tab · 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

Ticket timing exists only as a live on-screen artefact - the per-tile order timer and its colour-change duration thresholds - and is not persisted into any report. The help centre's Reports set is fully enumerable under Lavu Control Panel > Reports (Bank Deposit, Best Sellers, Change Bank, Daily Totals, General Ledger, Hourly Sales, Kitchen Change Log, Paid In/Out, Refund Summary, Register Sales, Sales by Category, Sales by Item, Super Groups, Time Cards, Voided Orders, Reopened Orders and the End of Day overviews); none reports actual ticket or per-station times, and Kitchen Change Log records edits rather than durations. https://support.lavu.com/en/knowledge/lavu-kds-settings-functions-and-features · retrieved 2026-09-04 adversarially verified

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

NEW SURFACE (323rd): PUBLIC SOURCE MAPS for Lavu's production Control Panel SPA. admin.poslavu.com serves the CRA shell but 404s its own /static assets; the live build is on https://prod-cp3-01.aws2.poslavu.com (Control Panel, production, a host from the 319th crt.sh list). Its index.html carries the inlined webpack runtime whose chunk-hash table names 96 lazy chunks; every one of them plus the two entry chunks returned a real map (99 maps, 4,955 sources, 1,818 own-source files after dropping node_modules and de-duplicating; scripts maps.mjs/build.mjs in .cache/q323/lavu). SOFT-200 CONTROL: https://prod-cp3-01.aws2.poslavu.com/static/js/main.NONSENSE.chunk.js.map and /zzznope.js both return the 26,777-byte SPA shell, so every 200 was byte-checked to start {"version":3. BOUND: this bounds the CP3 app only - menu editing, the extension marketplace and most of the back office are still the legacy PHP CP at prod-cp0-01.aws2.poslavu.com/cp (env-config.js REACT_APP_PHP_URL), and modules/cp3-menus contains ONLY the menu-transfer wizard. EVIDENCE: the 297-file modules/cp3-inventory-new module ships a demand-based PAR engine the 250-article help centre never described. locale/en/items.js enumerates 'par: Par', 'demand_per_day: Demand Per Day', 'suggested_buy_qty: Suggested Buy QTY', 'shelf_life: Shelf Life', and the field help inv_lavu_par_description reads "Lavu's calculation of PAR based on your current usage. This will be your default when ordering to PAR."; locale/en/vendor.js enumerates 'vendor.par_settings: PAR Settings', 'parsettingspanel.demand_per_day: Historical Data', 'parsettingspanel.safety_stock: Safety Stock'; views/Orders/labels.js carries 'order.item.orderToPAR: Order to PAR' and views/Orders/actions.js getVendorPARItem returns a 'parCalculation' that PurchaseOrder/CreateOrder.js writes onto the order line. The same record type covers PREP ITEMS (items.js: 'prep_ingredients_tab: Prep-Ingredients', 'add_prep_item: Add Prep-Ingredient', 'prep_recipe: Prep-recipe'; AddNewPrepItemForm.js state carries par/lowStockAlert/shelfLife), so a predicted quantity from historical usage is produced for prep items, not only purchased goods. PARTIAL not yes: the predicted quantity is surfaced in the back-office ordering flow and nothing in the 1,818 files surfaces it to kitchen staff as a daily prep task list - tokenised word-boundary controls over the whole census: 'forecast' 0, 'prep list' 0, 'pacing' 0. Weakest link: 'current usage' is inventory depletion, which the vendor does not here state is derived from sales. Retrieved 2026-09-17. https://prod-cp3-01.aws2.poslavu.com/static/js/main.f9caaa32.chunk.js.map · retrieved 2026-09-17 adversarially verified

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

OVERTURNED. Drivers are not absent from the product, only from the help centre. Lavu's Delivery and Routing extension is documented in Lavu's own 17 July 2014 release: "The iPad terminal displays delivery orders and lets staff assign drivers to those orders", with the extension "available for all Lavu iPad POS accounts" at $30 added to the monthly hosting fee; lavu.com currently markets "Lavu's driver management tools" and "You know where your drivers are". Named shortfall: driver-order assignment is the only limb evidenced. Driver clock-in/out as a distinct state, the in-store / on-run / returning assignment states, and per-driver run-history reporting are documented nowhere, the module is a paid add-on rather than base POS, and the 250-article support.lavu.com corpus contains no article on it at all - so the depth of the roster cannot be established and the evidence is grade D marketing. https://www.prnewswire.com/news-releases/lavu-includes-delivery-and-routing-extension-for-restaurant-ipad-pos-267481231.html · retrieved 2026-08-08 adversarially verified

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

delivery-dispatch-board

OVERTURNED. A delivery-order screen with driver assignment and multi-order batching is documented: "The iPad terminal displays delivery orders and lets staff assign drivers to those orders" and "Multiple Order Routing groups two or more orders together and Lavu maps out the most efficient route with turn by turn directions" - which is exactly the 2+ orders to one driver as a single run that the claim asks for. Named shortfall: the three status columns the claim also requires - an undispatched queue, driver availability, and elapsed time per order - are not described anywhere; the release only says the system manages "orders down to the minute" by factoring "delivery preparation, route duration, and time at the door". The feature is a paid $30/month extension, is absent from the 250-article help centre entirely, and the evidence is a vendor release, so no screen-level confirmation exists. https://www.prnewswire.com/news-releases/lavu-includes-delivery-and-routing-extension-for-restaurant-ipad-pos-267481231.html · retrieved 2026-08-08 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

OVERTURNED on the sequencing limb. Lavu's Delivery and Routing extension performs system-generated route sequencing: "Lavu will consider the options for the sequence of deliveries, and give you the best one" and "Multiple Order Routing groups two or more orders together and Lavu maps out the most efficient route with turn by turn directions" (17 July 2014, $30 added to the monthly hosting fee). Named shortfall: the claim additionally requires a live map view on the dispatch screen with geocoded stops, and the documented delivery of the route is to the driver, not to a dispatcher - "Drivers are provided with a map and directions to each delivery location via text message or printed receipt". No dispatcher-side live map is described, the module is a paid add-on absent from the 250-article help centre, and the evidence is a vendor release (grade D), which is below the A/B bar a differentiator `yes` would need in any case. https://www.prnewswire.com/news-releases/lavu-includes-delivery-and-routing-extension-for-restaurant-ipad-pos-267481231.html · retrieved 2026-08-08 adversarially verified

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

delivery-driver-tracking

CLAIM: captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen / the guest. VERDICT: no. The 326th bounded only the guest app (Lavu To Go). The dispatch side is now in hand too, and it is one-directional: Lavu's delivery product is the "Lavu Routing Package", whose documented workflow ends by handing the route OUT — "Choose a Vehicle. Use the dropdown menu to choose a driver. Add deliveries to the vehicle ... Tap Find Route to create a delivery route. Choose to Send to the route to the driver or Print Route" (https://support.lavu.com/hc/en-us/articles/218805488-Routing-And-Delivery, retired KB via Wayback id_, corroboration only). Nothing comes back: the driver is a dropdown value, there is no driver-facing app, and the only completion signal documented anywhere is a manual tick — "To mark a delivery as complete, enable the 'Delivered' box to the right of the delivery" (How do I setup Delivery Settings?). CONTROLS over the CURRENT 249-article census: driver 2 substring / 0 tokenised, GPS 0, "live map" 0, "track your order" 0, "driver app" 0, "driver assignment" 0; 'geofence' scores 1 and it is a MenuDrive DELIVERY ZONE tool tip ("This turns ON your default delivery zone or geofence zone(s) ... so that customers' delivery addresses will be cross-checked"), i.e. an address-validation polygon, not a driver position; 'ETA' scores 151 on a substring grep and 0 tokenised (detail/detailing). Over the 1,817-file CP3 back-office source corpus driver 0 and GPS 0. Together with the 326th's Lavu To Go source-map census (1,272 sources, driver 0, 'tracking' 4 all Google Analytics constants), all three of Lavu's own apps — POS back office, guest ordering, and the documented delivery workflow — have no driver position channel. BOUND — THE CENSUS THIS PASS BUILT (new: nobody had validated the Lavu KB as a census before). support.lavu.com is a HUBSPOT knowledge base, not Zendesk. Two independent publisher listings agree: (a) the sitemap names 249 /en/knowledge/ articles; (b) the HubSpot search API, never used on this host before — https://support.lavu.com/_hcms/search?term=<t>&type=KNOWLEDGE_ARTICLE&limit=50&offset=<n>, swept over 120 terms (script hs-sweep.mjs) — returns 241 unique articles and every one of them is inside the 249, 0 extra. CITED-SLUG VALIDATION: of 78 distinct support.lavu.com URLs cited in Lavu's own claims.jsonl, 72 are in the 249; the 6 that are not are 3 category index pages (/lavu-pos, /menu-drive, /lavu-equipment-hardware) and 3 URLs on the RETIRED Zendesk KB (/hc/en-us/articles/...), which now 404 (support.lavu.com/hc/en-us 301s to /en/knowledge). Corpus = 3,170,001 chars of article text. (c) HREF FIXPOINT run this pass over all 249 raw bodies re-fetched today (34.8 MB, script raw.mjs): 251 distinct /en/knowledge/ URLs are referenced from inside the bodies and exactly 7 are absent from the sitemap — and all 7 are CATEGORY index pages (lavu-pos, lavu-payroll, lavu-control-panel, lavu-equipment-hardware, lavu-pay, onboarding, menu-drive), ZERO orphan articles. The 249 is therefore a census of this publisher, not a floor. Second census: the Control Panel 3 SPA source-map corpus (prod-cp3-01.aws2.poslavu.com, 99 of 100 chunks, 1,817 first-party files, 4,127,475 chars). Third: the lavu.com WordPress site census (2,567,819 chars). RETIRED SURFACE RECOVERED THIS PASS, CORROBORATION ONLY (merge policy bars a no resting on retired docs): the pre-HubSpot Zendesk KB is indexed by Wayback CDX at 514 distinct /hc/en-us/articles/ URLs (cdx-hc.json); 17 fetched via /web/<ts>id_/. POISON PUBLISHED (all measured over the 249-article KB, 3,170,001 chars): 'DoorDash' scores 284 tokenised and it is SITE CHROME — it appears in 241 of the 246 article sections, because every page's footer carries a "DoorDash Restaurant Solutions" link; anyone grepping DoorDash on this corpus will read 284 as a marketplace feature. 'master' scores 16 tokenised and ALL SIXTEEN are chain CURRENCY settings ("Set Master Currencies", "master currency list", "converted to a master currency"), never a master terminal. 'failover' scores 8 tokenised and ALL EIGHT are one article about an internet uplink device ("a failover modem ... connected to a wireless data provider (like Verizon, AT&T, or T-Mobile)"), never a POS role. 'driver' scores 2 on a substring grep and 0 tokenised. Retrieved 2026-09-18. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-09-18 adversarially verified

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

delivery-zones-polygon

MenuDrive: "You can define a delivery area as a radius around your store or create custom delivery zones on a map using geofencing", and the documented mechanic is dragging the edges of the radius on a map to make zones with different fees. Shortfall: a deformable radius, not vertex-drawn arbitrary polygons; no drive-time isochrones and no ZIP/postcode list. https://support.lavu.com/en/knowledge/how-do-i-set-up-delivery · retrieved 2026-08-02 adversarially verified

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

Same doc: once a zone exists, "the delivery charge set on the ACP Location Profile page will be ignored and the delivery charge set on the Customize Your Delivery Zones page will be the charge applied" — per-zone fee override, documented. https://support.lavu.com/en/knowledge/how-do-i-set-up-delivery · retrieved 2026-08-01 adversarially verified

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

MenuDrive validates the guest address against the configured delivery geometry at checkout: "the system will check to see if his or her delivery address is in your defined area", and a guest outside the boundary is notified rather than allowed to place the order. Boundary is either a radius around the store or a map-drawn geofence. https://support.lavu.com/en/knowledge/how-do-i-set-up-delivery · retrieved 2026-08-02

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

Downgraded from `no` on 2026-08-08. The `no` was built entirely on the claim that 'orders cannot be attributed to a driver at all', and that is false: Lavu's Delivery and Routing extension "lets staff assign drivers to those orders" (Lavu release, 17 July 2014, $30 added to the monthly hosting fee) and lavu.com still markets driver management. With the driver-order linkage restored, nothing forecloses per-run compensation capture, and the researcher's own caveat was that Lavu Payroll's earning-code surface was never enumerated. Positively, no evidence was found either way for per-run mileage or distance, a per-delivery flat reimbursement value, or a reimbursement-versus-wage split on the payroll export; 'mileage' and 'reimburse' have zero occurrences in the 250-article help centre, but that corpus demonstrably omits the delivery extension itself. Undetermined. || 327th: NEW SURFACES AND A DIRECT CONTRADICTION INSIDE LAVU'S OWN PUBLICATIONS — recorded so the next pass does not re-find it, and the reason this cell must NOT be written as a no. (a) The product documentation has no driver-compensation surface at all: over the 249-article support.lavu.com census (see the census note on delivery-offline-behavior) mileage 0, reimbursement 0, "driver pay" 0, "per delivery" 0, driver 2 substring / 0 tokenised; over the 1,817-file Control Panel 3 source corpus mileage 0, reimbursement 0, driver 0. Lavu's own delivery workflow documentation treats the driver as a dropdown value on a vehicle ("Use the dropdown menu to choose a driver", Routing And Delivery) and its delivery-money article is about charging the GUEST, not paying the driver ("Lavu provides multiple options for configuring and applying Delivery Charges to an Order ... The Gratuity function can be repurposed for use as a Delivery Charge", FAQ: Delivery Charges). (b) AGAINST THAT, lavu.com's WordPress blog — vendor-authored but grade C, and visibly programmatic SEO (dozens of "Labor Cost for <segment> in <state>" pages) — asserts the capability twice: "Driver management features track mileage and tips directly through the POS. This improves compliance and accuracy" and "How do I accurately track driver tips and mileage for compliance? Use a reliable POS system like Lavu. It tracks sales, tips, and manages delivery routes for accurate compliance reporting." Over that WP census mileage scores 29 tokenised, drivers 101, reimbursement 4 — all of it blog prose. Held unknown: a marketing assertion cannot carry a yes on a differentiator (needs A or B) and it forbids a no, and NO conjunct of the claim — mileage or distance per run, per-delivery flat reimbursement, driver-retained tips, payroll export as separate reimbursement vs wage lines — is documented anywhere in the product corpora, so there is no partial either. WOULD RESOLVE: the Lavu Payroll module's earnings-code documentation, which is not in the public KB. Retrieved 2026-09-18. || 328th: 328th: THE 327th'S STANDING OBJECTION - that the 249-article corpus 'demonstrably omits the delivery extension itself' - IS NOW CLOSED, AND THE EXTENSION'S SETTINGS STILL HOLD NO COMPENSATION FIELD. The 342-article retired Zendesk corpus recovered this pass (census on payments-surcharge-guardrails) contains the delivery module's own configuration articles, which no prior corpus held: 'Routing And Delivery' enumerates the Routing package settings exhaustively - 'Define the Starting Address, Starting City, Starting State, & Starting Postal Code' then 'Define Delivery Earliest Departure, Delivery Window, Time at Delivery Location and click Save' - and 'How do I setup Delivery Settings?' enumerates the delivery settings as 'Using Customer Delivery', 'Delivery Button 1, 2, 3' and 'Button Interval'. The driver remains a dropdown value assigned to a vehicle ('Choose a Vehicle... Use the dropdown menu to choose a driver... Tap Find Route'). Over all 1,065,356 chars: mileage 0, reimburs 0, 'driver pay' 0. STILL NOT A no, for the same reason the 327th gave: this is a retired copy of the docs (merge policy bars a `no` resting on retired docs), the retrieval is a floor (342 of 514 CDX rows), and Lavu Payroll's earning-code surface is still unenumerated. ALSO NEW AND DELIBERATELY NOT USED: lavu.com's WordPress blog census carries vendor-authored FAQ prose that reads like a positive - 'Delivery management apps track routes, tips, and mileage. They ensure accurate driver pay and reporting' and 'How do I accurately track driver tips and mileage for compliance? Use a reliable POS system like Lavu.' Both are generic category advice about 'delivery management apps', not a statement that Lavu captures mileage; a blog census is grade C and cannot carry this differentiator either way. Retrieved 2026-09-18. || 330th: 330th: NEW SURFACE, NO MOVE - the 327th's 'WOULD RESOLVE' item (Lavu Payroll's earnings surface) is now partly read and it holds no reimbursement line, but it is still not an enumeration of earning codes. 'How to Run Payroll' (support.lavu.com/how-to-run-payroll, current) walks the entire payroll run and the ONLY per-employee money inputs it names are tips: 'This is also where you will need to update Tip information for the pay period. Next to Paycheck Tips, enter the amount of tips that are paid to your employees directly on their paycheck ... Next to Cash Tips, enter the amount of tips your employee has received in cash', then Preview Payroll / Submit Payroll. No mileage, distance, per-delivery amount or reimbursement-vs-wage line appears in the run, and 'driver' now scores 0 TOKENISED across the whole 245-article current help centre (3,150,753 chars) - i.e. the current KB documents no driver-compensation surface at all, and its only delivery-money article is 'Menu Drive - How do I set up delivery?', which prices ZONES charged to the guest ('a $2.00 charge is appropriate for deliveries in that area'), not the driver. Still unknown rather than no: the payroll article is a run walkthrough, not an earning-code catalogue (a reimbursement code could be defined in employee setup, which the KB does not enumerate), and lavu.com's vendor-authored blog still asserts the opposite in one Lavu-specific sentence ('Driver management features track mileage and tips directly through the POS'), which forbids a no on a differentiator even at grade C. Retrieved 2026-09-18. adversarially verified

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

delivery-cash-reconcile

Lavu ships two settle-up flows: Cash Reconciliation for a shared till, and - per this article's own note - Server Reconciliation 'if you have specific employees tied to specific cash tills'. Either tills in and out by denomination, tracks 'every cash transaction, card tip, refund, deposit, refunded deposit, pay in, and pay out', and on close prints a till summary including 'your variance, or the difference between what you entered and what Lavu calculated you should have'; the add/subtract/ignore treatment of each Till-In/Till-Out line is configurable under Advanced Location Settings - Account Settings. Shortfall: this is a generic per-employee bank, not a driver settle-up. Orders carry no driver linkage (no driver field in the public order schema), so 'orders assigned' and driver-retained tips owed are not part of the reconciliation, and no delivery-specific over/short is produced. https://support.lavu.com/en/knowledge/management-tools-cash-reconciliation · retrieved 2026-08-08

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

delivery-daas-dispatch

Positive evidence of absence, stated as the article's own premise. MenuDrive's delivery guide is written for the operator who says 'I have staff to deliver ... I am not interested in using a third-party delivery service', and the whole configured surface is in-house: the order-type toggle, a radius or geofenced zones, per-zone charges, and zone enforcement at checkout. Lavu's only courier-marketplace surface is the DoorDash DSP integration, which ingests orders placed on DoorDash rather than handing a first-party order to a courier; no DoorDash Drive, Uber Direct, Nash or Relay handoff exists in the complete 249-article help centre or in the api.lavu.com OpenAPI spec. https://support.lavu.com/en/knowledge/how-do-i-set-up-delivery · retrieved 2026-09-04 adversarially verified

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

delivery-daas-fallback

Hybrid overflow presupposes a courier handoff that does not exist. The delivery configuration the article enumerates has exactly one failure branch and it is refusal, not escalation: an out-of-zone address triggers a message and the guest is 'asked if he or she wants to resume with pickup or use another delivery address'. There is no driver-availability condition, no wait threshold, and no rule that routes an order to a third-party courier. https://support.lavu.com/en/knowledge/how-do-i-set-up-delivery · retrieved 2026-09-04 adversarially verified

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

delivery-3p-direct-integration

Partial is right but the researcher's reasoning was wrong in both directions. Lavu's own integrations page annotates DoorDash, Grubhub, Uber Eats and Xero with "Integration available with integrator" — affirmative evidence those are middleware-brokered, which the researcher did not find. But the DSP support doc shows a genuinely direct Lavu DSP→DoorDash API path. So: DoorDash direct (US only), Uber Eats and Grubhub integrator-mediated. Partial stands on corrected evidence. https://lavu.com/integrations/ · retrieved 2026-08-01 adversarially verified

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

delivery-3p-injection

DSP Integration doc describes a first-party pipe: "MenuDrive sends the request to Lavu DSP, then Lavu DSP calls the DoorDash API, finally DoorDash confirms the store activation to Lavu DSP", and "Orders from DoorDash go straight to the kitchen". US-only; explicitly not available for Mexico locations. https://support.lavu.com/en/knowledge/dsp-integration-delivery-service-provider-integration · retrieved 2026-08-01 adversarially verified

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

delivery-menu-push

Same doc documents a "Sync Menu" function with progressive POS→MenuDrive sync propagating to DoorDash. 86 sync and store pause remain undocumented. https://support.lavu.com/en/knowledge/dsp-integration-delivery-service-provider-integration · retrieved 2026-08-01 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

Documented POS-to-marketplace availability sync: "The DoorDash and Lavu POS integration automatically adds inventory tracking to DoorDash. If an item is out of stock on the POS, then the item will automatically be removed from the DoorDash storefront." Doc states this works from either Item Level 86 Tracking or the Lavu inventory platform. https://support.lavu.com/en/knowledge/lavu-menu-drive-and-door-dash · retrieved 2026-08-02

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

Temporary-closure control in the DoorDash integration screen: a slider activates the closure and the operator selects when the store automatically reopens; the doc states it "will immediately prevent your customers from submitting orders" through DoorDash. Scheduled auto-reopen is part of the same control, so the operator is not required to remember to unpause. https://support.lavu.com/en/knowledge/lavu-menu-drive-and-door-dash · retrieved 2026-08-02

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

delivery-3p-reconciliation

The DoorDash integration article enumerates every screen it adds to the MenuDrive Control Panel - Delivery Providers with Connect/Onboard, Sync Menu, out-of-stock sync, dual pricing, temporary closures, special store hours - and none of them reports money. Payout deposits, commission, marketing fees and adjustments are not surfaced on the Lavu side at all, and the MenuDrive reporting set (Menu Drive - All Reports, automated reports, Coupon Reports, Google Analytics) reports orders and coupons rather than marketplace remittance, so there is nothing to match deposits against POS-recorded 3P sales. https://support.lavu.com/en/knowledge/lavu-menu-drive-and-door-dash · retrieved 2026-09-04 adversarially verified

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

delivery-injection-error-visibility

Menu-sync health is surfaced to the operator: 'If the sync fails, it throws an error and asks you to try again', with last-sync date/time shown on the Delivery Providers page, which also shows the DoorDash connection state. Shortfall: order-level injection failures are not surfaced - no alerting or failed-order queue is documented for order ingestion. https://support.lavu.com/en/knowledge/dsp-integration-delivery-service-provider-integration · 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

Guest-facing status exists but is order-state only. From the Order Dashboard the operator taps Confirm, checks 'send confirmation' and picks a ready time, which 'send[s] an email to the customer' with the estimated prep time; on the storefront, registered customers 'can select from various pages to manage their account' including Order History, where they can also provide feedback. Shortfall: there is no branded tracking page driven by real driver state - no driver entity exists anywhere in the product (the public order schema has no driver field) - and no SMS status link to the guest is documented; MenuDrive's 'text notifications' order-receiving method notifies the restaurant, not the guest. https://support.lavu.com/en/knowledge/menu-drive-order-dashboard · retrieved 2026-08-08

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

Positive evidence of the excluded mechanism: the quote is a fixed per-store constant by design. Preparation Time is set per fulfilment type on the Location Profile and the worked example applies it unconditionally - a 30-minute setting tells an 8:25 p.m. guest the order will be ready 'around' 8:55 - with the only documented adjustment being an operator editing the pickup/delivery hours. Kitchen load, driver availability and zone drive time are not inputs; the delivery zones the operator draws carry a charge, not a duration. https://support.lavu.com/en/knowledge/menu-drive-order-types-and-prep-time · retrieved 2026-09-04 adversarially verified

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

delivery-offline-behavior

CLAIM: vendor documents explicit offline behavior for delivery — whether cash delivery orders, driver assignment and driver settlement continue during an internet outage. VERDICT: no. Lavu DOES publish explicit offline documentation, twice, and both documents are CLOSED ENUMERATIONS that never mention delivery, drivers or settlement. (1) Current KB, "Lavu Crash Kit 101" (https://support.lavu.com/en/knowledge/lavu-crash-kit-101): "It's also important to know what you CAN do even if the POS suffers any performance issues. Conduct cash transactions / Open the cash drawer / Add food and drink to open orders / Start new orders / Send orders to the kitchen / Print checks. None of the features above require an internet, or database connection. Most notably what is missing, are credit card and gift card transactions." It then offers three mitigations — the CardPointe virtual terminal, Lavu Pay iDynamo "Store & Forward" ("the details will be stored in memory within the iPad itself. Once you are back online, all card details captured will slowly begin to process"), and a failover modem. Six offline-capable functions are listed; delivery is not one of them, and no delivery/driver behaviour is stated either way. (2) CORROBORATION from the retired Zendesk KB, "Offline Order Sync (P2P Mode)" (https://support.lavu.com/hc/en-us/articles/360026467394-Offline-Order-Sync-P2P-Mode-, recovered via Wayback id_), whose "Current Limitations" list while offline is also closed — "The Server Tips page / Pizza Creator / Front of House reports like the Server Summary and X Report / Clocking in and out / 86 countdowns / Inventory / Manager Functions / Lavu Gift/Loyalty / Max of 8 devices" — again with no delivery entry, although Lavu's Routing Package (driver/vehicle assignment) existed at the time. CONTROLS over the 249-article census: driver tok 0, dispatch 0, mileage 0, "driver assignment" 0, settlement 0; 'delivery' scores 94 and none co-occurs with an outage. POISON ON THIS CELL: 'settlement' scores 2 tokenised and BOTH are card-batch settlement with the processor ("Simply click Settle batch button to initiate a batch settlement with your gateway"), not driver settlement; 'ETA' scores 151 on a substring grep and 0 tokenised (it is inside detail/detailing/details). BOUND — THE CENSUS THIS PASS BUILT (new: nobody had validated the Lavu KB as a census before). support.lavu.com is a HUBSPOT knowledge base, not Zendesk. Two independent publisher listings agree: (a) the sitemap names 249 /en/knowledge/ articles; (b) the HubSpot search API, never used on this host before — https://support.lavu.com/_hcms/search?term=<t>&type=KNOWLEDGE_ARTICLE&limit=50&offset=<n>, swept over 120 terms (script hs-sweep.mjs) — returns 241 unique articles and every one of them is inside the 249, 0 extra. CITED-SLUG VALIDATION: of 78 distinct support.lavu.com URLs cited in Lavu's own claims.jsonl, 72 are in the 249; the 6 that are not are 3 category index pages (/lavu-pos, /menu-drive, /lavu-equipment-hardware) and 3 URLs on the RETIRED Zendesk KB (/hc/en-us/articles/...), which now 404 (support.lavu.com/hc/en-us 301s to /en/knowledge). Corpus = 3,170,001 chars of article text. (c) HREF FIXPOINT run this pass over all 249 raw bodies re-fetched today (34.8 MB, script raw.mjs): 251 distinct /en/knowledge/ URLs are referenced from inside the bodies and exactly 7 are absent from the sitemap — and all 7 are CATEGORY index pages (lavu-pos, lavu-payroll, lavu-control-panel, lavu-equipment-hardware, lavu-pay, onboarding, menu-drive), ZERO orphan articles. The 249 is therefore a census of this publisher, not a floor. Second census: the Control Panel 3 SPA source-map corpus (prod-cp3-01.aws2.poslavu.com, 99 of 100 chunks, 1,817 first-party files, 4,127,475 chars). Third: the lavu.com WordPress site census (2,567,819 chars). RETIRED SURFACE RECOVERED THIS PASS, CORROBORATION ONLY (merge policy bars a no resting on retired docs): the pre-HubSpot Zendesk KB is indexed by Wayback CDX at 514 distinct /hc/en-us/articles/ URLs (cdx-hc.json); 17 fetched via /web/<ts>id_/. POISON PUBLISHED (all measured over the 249-article KB, 3,170,001 chars): 'DoorDash' scores 284 tokenised and it is SITE CHROME — it appears in 241 of the 246 article sections, because every page's footer carries a "DoorDash Restaurant Solutions" link; anyone grepping DoorDash on this corpus will read 284 as a marketplace feature. 'master' scores 16 tokenised and ALL SIXTEEN are chain CURRENCY settings ("Set Master Currencies", "master currency list", "converted to a master currency"), never a master terminal. 'failover' scores 8 tokenised and ALL EIGHT are one article about an internet uplink device ("a failover modem ... connected to a wireless data provider (like Verizon, AT&T, or T-Mobile)"), never a POS role. 'driver' scores 2 on a substring grep and 0 tokenised. Retrieved 2026-09-18. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-09-18 adversarially verified

Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.

digital-first-party-web

MenuDrive by Lavu is a first-party ordering site on the restaurant’s own branding that writes into the POS, positioned to keep "your customers ordering from you – not third parties". Shortfall: the claim requires it be commission-free, and Lavu publishes no MenuDrive commercial terms anywhere — no per-order fee, no rate card, no statement that no commission applies. Scoring yes would assume an unpublished term favourable. https://lavu.com/online-ordering/ · retrieved 2026-08-02 adversarially verified

The web/app ordering menu is generated from the same POS menu record as in-store — one item edit propagates to all first-party digital channels without a separate digital menu build.

digital-menu-single-source

The 'POS Menu Auto-Sync with MenuDrive' feature 'helps business owners to manage the same menus on both platforms (Lavu POS & MenuDrive) from a single point of origin', and propagates onward: 'Lavu POS menu will take up to 5 minutes to get updated from Lavu POS to the MenuDrive and another 2 minutes to update it to the DoorDash menu.' Shortfalls: MenuDrive is a separate menu record with its own builder (basic-menu-building-in-menu-drive), and only 'locked' MenuDrive items sync - 'Any unlocked menu items in the MenuDrive will be exempted from the sync process'; the operator cannot enable it themselves ('a representative from the Customer Success team will enable the POS Sync V2 option'); and MenuDrive QR dine-in ordering runs on a separate MenuDrive location whose menu the customer success team copies over, so that channel is a second build. https://support.lavu.com/en/knowledge/auto-sync-your-menu-drive-menu-with-lavu-pos · retrieved 2026-08-08

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

Positive absence across the product's own documentation index. The Menu Drive category page enumerates all forty of its articles under Order Receiving Methods, Marketing, Reports, Menu Building, Payments, Settings, General Walkthrough, Design Settings and DoorDash; the guest-facing artefact throughout is a hosted web storefront (each location gets an orders.<name> URL) styled through Design Settings and the Photo Manager and reached by QR code. No article covers publishing a branded iOS or Android app, and menudrive.com's own feature catalogue lists storefront and template tooling with no app build. The only Lavu-published App Store title is the operator-side Lavu POS client. https://support.lavu.com/en/knowledge/menu-drive · retrieved 2026-09-04 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

MenuDrive storefront supports registered guest accounts: customers "create an account within your storefront", then manage contact information, saved credit card numbers and a saved delivery address "for faster ordering", plus order history. Account-creation form fields are configurable by the operator in the Control Panel. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-02

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

'Built-in upsell and add-on marketing' in MenuDrive; no attach-rate reporting documented. https://lavu.com/online-ordering/ · retrieved 2026-08-01

Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.

digital-scheduled-pacing

Named shortfall: scheduling exists, pacing does not. Checkout exposes "Order Pickup Time" with ASAP and Advanced options, so a guest can place an order for later. No throttle, capacity-per-interval, quote-time stretch or blackout-slot control is documented anywhere in the storefront, checkout or Location Profile articles — the same gap the 86-count doc exposes, where advance orders are explicitly outside availability tracking. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-02

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

Named shortfall: only two fulfillment modes are documented. The storefront order-type popup lets a guest choose "what kind of order they would like (ASAP vs. Advanced, Pick Up vs. Delivery, etc.)". Pickup and delivery are documented; curbside, dine-in/table and drive-up modes appear nowhere in the storefront or checkout articles. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-02

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

QR scan-to-pay from the printed receipt is documented; scan-to-order attaching to an open POS check, splitting and tipping are not. https://lavu.com/contactless-payments-ordering/ · retrieved 2026-08-01

Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator

digital-kiosk

A first-party kiosk ships — help-centre articles "Lavu Kiosk - Order Workflow", "Lavu Kiosk - Basic Customization" and "Lavu Kiosk - Receipt Printers", plus a monitored Kiosk status component. Shortfall: the claim also requires accessibility-compliant UI and unattended EMV payment; Lavu publishes no ADA/WCAG conformance statement and names no unattended payment device. https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-02 adversarially verified

Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.

digital-group-ordering

Positive absence by enumeration of the ordering product's whole documented surface: the forty Menu Drive articles cover the storefront, order types, prep time, delivery zones, payments (tips, taxes, custom options), coupons, loyalty, email automations, QR codes, menu building and reporting. Nothing creates a shareable multi-participant cart, a per-person or total spend cap, or a payment split across participants; MenuDrive checkout is one guest, one order, on the account-and-saved-payment model documented in the storefront article. https://support.lavu.com/en/knowledge/menu-drive · retrieved 2026-09-04 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

MenuDrive covers slices of catering: per-item 'MIN OR MAX PER ORDER' is 'especially helpful with catering menus where there is a 5 person minimum', item visibility supports 'advanced ordering', and stores can accept Advance Orders alongside ASAP. Shortfalls: no separate catering ordering flow or menu, no lead-time rules beyond prep time, no quotes/proposals, no deposits online, and no invoice/house-account or ACH payment terms. https://support.lavu.com/en/knowledge/menu-items-advanced-settings · 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

326th: MOVED unknown -> no ON AN EXPLICIT VENDOR SELF-STATEMENT, not on silence. lavu.com was REBUILT around 'Marty AI' ('All Lavu products are powered by Marty AI') since this record's corpus was taken, and the new page https://lavu.com/2026-restaurant-pos-ai-capabilities-report/ publishes a feature matrix headed 'AI Feature | Lavu (Marty) | Toast IQ | Square AI' in which Lavu marks ITSELF absent on this exact capability: the row 'AI-powered voice phone ordering' carries <td data-label="Lavu (Marty)" class="no">✗ No</td>, against Square AI '✓ Yes'. READ FROM RAW HTML, NOT FROM STRIPPED TEXT: every cell is its own <td> with a data-label naming its column, so the attribution is explicit and this is not the welded-table artefact that has faked quotes elsewhere in this atlas; Lavu also marks itself '✗ No' on 'In-chat task execution' and 'AI marketing campaign creation' in the same table, so the column is not a puff column. Lavu dates it 'Feature comparison from publicly available product documentation and vendor press releases, February 2026'. BOUND AND CONTROLS over a 11.5 MB corpus (the 245-article support.lavu.com KB dump re-derived today against the live sitemap - 249 loc entries, 0 slugs absent from the dump, so the KB is unchanged since 2026-08-08; the full lavu.com WordPress REST census, 344 items / 2,567,819 chars; the Control Panel 3 source-map corpus; the newly mapped Lavu To Go ordering app; api_doc.html and the api.lavu.com swagger): 'voice ordering' 3, 'voice AI' 2, 'AI voice' 2 - ALL of them BLOG TITLES in related-post lists ('Voice AI for Restaurants: Phone Ordering Without the Hold Time', 'AI Voice Ordering for Drive-Through Restaurants'), i.e. content marketing about the category, never a product claim; IVR 0, PBX 0, 'phone system' 0. POISON PUBLISHED: 'voice' scores 1,187 on a substring grep and 19 tokenised - the 1,168 are INVOICE - and of the 19, twelve are one syndicated support review ('instructions on how to fix the kitchen printer were provided through a voice and video call'), four are the blog titles, one is the comparison row above, one is a competitor description, and one is the legacy API's <voice_auth> card field. Retrieved 2026-09-18. https://lavu.com/2026-restaurant-pos-ai-capabilities-report/ · retrieved 2026-09-18 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 lane in the product for a voice agent to sit in front of. Order Types enumerates the shipped order flows as Dine In, Pickup and Carry Out across the Quick Serve, Tables and Tabs service layouts, and 'drive-thru' occurs zero times in the complete 249-article help centre or the 4,844-URL first-party sitemap census. Lavu sells no lane hardware - no speaker post, headset or confirmation display - in its forty-product store, and no AI voice surface of any kind, escalation path included, is documented anywhere. https://support.lavu.com/en/knowledge/order-types · retrieved 2026-09-04 adversarially verified

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

digital-sms-ordering

Positive absence by enumeration. SMS appears in MenuDrive only as an order-receiving alert to the operator - menudrive.com/how-it-works lists 'Accept orders through email, text, and/or your online dashboard' - and the Order Receiving Methods articles configure that outbound notification. No article in the forty-article Menu Drive set, or anywhere in the 249-article help centre, documents a guest-facing conversational SMS or chat ordering path that lands an order in the POS, and Lavu's campaign tooling is email-only (Marketing - Email Automations, with a built-in or custom mail server). https://support.lavu.com/en/knowledge/menu-drive · retrieved 2026-09-04 adversarially verified

Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator

digital-google-order

326th: MOVED unknown -> no, and it closes the lead the 319th opened. The 319th found local.lavu.com (a Merchynt/Paige white-label that MANAGES Google Business Profiles for Lavu merchants) but could not bound the absence of ordering-link provisioning because a white-label bundle is not a census of Lavu. Three vendor-authored surfaces now bound it. (1) lavu.com's ordering/delivery partner enumeration on lavu.com/integrations/ names Otter, Chowly, DoorDash, Grubhub, Uber Eats, Flipdish, Checkmate and Open Dining and no Google surface. (2) The full lavu.com WordPress REST census taken today (344 pages+posts, 2,567,819 chars, incl. every marketing page for Online Ordering, Digital Ordering and Marty AI): 'order with google' 0, 'Google Business Profile' 2 and both are BLOG TITLES in related-post lists ('How to Set Up Restaurant Google Business Profile Optimization'), never a provisioning feature. (3) A NEW SURFACE - the Lavu To Go guest ordering app, whose complete CRA source map I recovered today at https://prod-olo-01.aws2.poslavu.com (asset-manifest.json -> static/js/main.683ad004.js.map, 16.9 MB, 1,272 sources of which 152 are first-party, 889,439 chars; SOFT-200 CONTROL PASSED: /zzz-nonsense-manifest.json and static/js/main.NONSENSE.js.map both return the 1,314-byte SPA shell while the real map begins {"version":3,). In that app 'google' is 26 substring hits and every one is ANALYTICS plumbing - merchant settings ltg_google_analytics_tracking_id and ltg_google_tag_management_id, ReactGA and GTM initialisation - with no ordering-link, place-action or Google-provisioned entry point anywhere in the storefront that such a link would have to target. Retrieved 2026-09-18. https://lavu.com/integrations/ · retrieved 2026-09-18 adversarially verified

Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.

digital-apple-business-connect

CLAIM: 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. VERDICT: no. CONTROLS, tokenised and case-insensitive, over three independent censuses simultaneously — the 249-article support.lavu.com KB (3,170,001 chars), the 1,817-file Control Panel 3 source-map corpus (4,127,475 chars) and the lavu.com WordPress site census (2,567,819 chars): "Apple Business Connect" 0/0/0, "Apple Maps" 0/0/0, "place card" 0/0/0, "custom action" 0/0/0, "Order Food" 0/0/0. ASYMMETRY that makes the silence meaningful: Lavu DOES document listing placement when it has it — its listings product is local.lavu.com ("Lavu Local"), a white-label of Merchynt's Paige, and it manages GOOGLE Business Profiles only; and the current KB documents the ordering channels it does have (MenuDrive online ordering, Lavu QR codes with Up'n Go, kiosk). Apple appears in the Lavu corpora only as the hardware vendor (iPad, iOS, Apple Mac mini) and as Apple Pay. BOUND — THE CENSUS THIS PASS BUILT (new: nobody had validated the Lavu KB as a census before). support.lavu.com is a HUBSPOT knowledge base, not Zendesk. Two independent publisher listings agree: (a) the sitemap names 249 /en/knowledge/ articles; (b) the HubSpot search API, never used on this host before — https://support.lavu.com/_hcms/search?term=<t>&type=KNOWLEDGE_ARTICLE&limit=50&offset=<n>, swept over 120 terms (script hs-sweep.mjs) — returns 241 unique articles and every one of them is inside the 249, 0 extra. CITED-SLUG VALIDATION: of 78 distinct support.lavu.com URLs cited in Lavu's own claims.jsonl, 72 are in the 249; the 6 that are not are 3 category index pages (/lavu-pos, /menu-drive, /lavu-equipment-hardware) and 3 URLs on the RETIRED Zendesk KB (/hc/en-us/articles/...), which now 404 (support.lavu.com/hc/en-us 301s to /en/knowledge). Corpus = 3,170,001 chars of article text. (c) HREF FIXPOINT run this pass over all 249 raw bodies re-fetched today (34.8 MB, script raw.mjs): 251 distinct /en/knowledge/ URLs are referenced from inside the bodies and exactly 7 are absent from the sitemap — and all 7 are CATEGORY index pages (lavu-pos, lavu-payroll, lavu-control-panel, lavu-equipment-hardware, lavu-pay, onboarding, menu-drive), ZERO orphan articles. The 249 is therefore a census of this publisher, not a floor. Second census: the Control Panel 3 SPA source-map corpus (prod-cp3-01.aws2.poslavu.com, 99 of 100 chunks, 1,817 first-party files, 4,127,475 chars). Third: the lavu.com WordPress site census (2,567,819 chars). RETIRED SURFACE RECOVERED THIS PASS, CORROBORATION ONLY (merge policy bars a no resting on retired docs): the pre-HubSpot Zendesk KB is indexed by Wayback CDX at 514 distinct /hc/en-us/articles/ URLs (cdx-hc.json); 17 fetched via /web/<ts>id_/. POISON PUBLISHED (all measured over the 249-article KB, 3,170,001 chars): 'DoorDash' scores 284 tokenised and it is SITE CHROME — it appears in 241 of the 246 article sections, because every page's footer carries a "DoorDash Restaurant Solutions" link; anyone grepping DoorDash on this corpus will read 284 as a marketplace feature. 'master' scores 16 tokenised and ALL SIXTEEN are chain CURRENCY settings ("Set Master Currencies", "master currency list", "converted to a master currency"), never a master terminal. 'failover' scores 8 tokenised and ALL EIGHT are one article about an internet uplink device ("a failover modem ... connected to a wireless data provider (like Verizon, AT&T, or T-Mobile)"), never a POS role. 'driver' scores 2 on a substring grep and 0 tokenised. Retrieved 2026-09-18. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-09-18 adversarially verified

Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.

digital-loyalty-attach

Named shortfall: redemption online, accrual undocumented online. The MenuDrive storefront lets a signed-in customer "redeem loyalty points for discounts", so the online channel reads the loyalty balance. But the POS-side award flow requires staff to select Lavu Loyalty and key or scan a loyalty card at checkout, and no article documents points being earned on a MenuDrive web order or the two identities being merged. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-02

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

Positive absence by enumeration of the guest-monetisation surface. MenuDrive's retention tooling is fully documented and consists of coupons, a points-based loyalty program with redeemable rewards, email automations and announcements; the coupon object exposes discount type, validity dates, login requirement, usage limits, minimum subtotals and public/private, with no recurring charge, entitlement period or membership tier. Nothing in the Menu Drive or Lavu Gift/Loyalty sets bills a guest on a schedule or waives fees for a paid tier. https://support.lavu.com/en/knowledge/menu-drive · retrieved 2026-09-04 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

Named shortfall: online coupons are a separate object from POS discounts. The storefront checkout includes a "Coupon Codes" section and MenuDrive carries its own Coupon Reports showing "the amount of money your customers have saved by using coupons and the average discount per order". Lavu POS discounts are configured independently under Settings > Payment > Discount Types in the Control Panel; no shared promotion record or parity-enforcement between the two is documented. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-02

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

ToS grants Lavu a perpetual, irrevocable, sublicensable license over user content including AI training, and states Lavu 'has no obligation to... allow extraction of User Content or User Data post-termination'. No operator bulk-export right is documented. https://lavu.com/terms-of-service/ · retrieved 2026-08-01

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

Checkout runs entirely on the vendor-hosted storefront (each location gets 'https://orderstart.com/<the name of the restaurant>'), so card entry never touches a restaurant-owned page, and Lavu publishes that its software and readers are PCI compliant, with Lavu Pay compliance maintained 'through your card reader and your CardConnect account'. Shortfalls: no published PCI DSS 4.0 attestation (the compliance article is generic) and no documented 3DS/SCA support for MenuDrive checkout. https://support.lavu.com/en/knowledge/menu-drive-location-profile · retrieved 2026-08-05

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 digital channel does carry payment-conditional fees: MenuDrive's Payments > Custom Options page creates custom charges 'on all orders, orders paid with cash only, or orders paid with cards only', fixed or percentage, named as they appear on the guest's receipt; and lavu-menu-drive-and-door-dash documents a Dual Pricing percentage applied to the DoorDash storefront ('We recommend a dual pricing increase of 5%'). Shortfalls: this is not the POS configuration - the Cash Discount Program article scopes CDP to the register (two prices shown at checkout, both totals on the printed check), is 'only available in the U.S., and to Lavu Pay customers', and never mentions MenuDrive; the digital surcharge is a separately configured custom charge rather than the same dual-price record. No guest-facing disclosure text, no jurisdiction list and no card-brand prohibition handling is documented for any channel. https://support.lavu.com/en/knowledge/menu-drive-payments-custom-options · retrieved 2026-08-08

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

Named shortfall: the identity is a card, not a person. Loyalty is attached at checkout by entering "the customer's loyalty number" or scanning their card, and the Control Panel Gift & Loyalty Cards page keys balances and history to the card record. A MenuDrive registered account is a separate record with its own credentials, saved cards and address. No documented merge, lookup-by-phone/email, or single guest profile spanning POS, online ordering and gift/loyalty. https://support.lavu.com/en/knowledge/awarding-loyalty-points-and-redeeming-loyalty-discounts · retrieved 2026-08-02

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 public order schema does carry a guest object - LavuApiOrderSerializer has a `customer` member (LavuApiCustomer: f_name, l_name, email, phone, street, city, state, zip) plus togo_name/togo_phone and an order-level email - so a marketplace order could in principle arrive attached. But nothing documents that it does: dsp-integration-delivery-service-provider-integration walks store onboarding, menu export and order ingestion and specifies only that 'the financial details for each DX order' (item price, modifier price, taxes, tips) now display, and lavu-menu-drive-and-door-dash covers connection, menu sync, 86 handling, dual pricing and store hours. Neither says what guest identity accompanies the order. Lavu's own loyalty identity is a loyalty number or barcoded physical card presented at the register, which is not a channel-independent guest profile. Uber Eats and Grubhub appear nowhere in the 250-article support.lavu.com help centre dumped 2026-08-08 (sitemap plus cross-linked articles). Unresolved. || 327th: NEW SURFACE, no move, and a poison that would have manufactured a false yes. Over the 249-article support.lavu.com census (bound described on delivery-offline-behavior) 'DoorDash' scores 284 TOKENISED — and it is site chrome: it occurs in 241 of the 246 article sections, because every page footer carries a "DoorDash Restaurant Solutions" link. Not one of those 284 is an article about marketplace orders. Against that count, "Uber Eats" 0, Grubhub 0, Otter 0, Deliverect 0, Chowly 0, marketplace 0, "guest profile" 0, "third-party" 1 tokenised across the whole KB. Lavu's own integration directory (https://lavu.com/pos-integration/) DOES name DoorDash, Uber Eats, Grubhub, Otter and Chowly, so marketplace orders do reach the POS — but by aggregator middleware, and the directory is a partner list with no field-level behaviour, while Lavu's native guest record is the "Customer Management" module (11 tokenised hits, all first-party order entry: "Tap the Customer Management bar. Enter a new customer's information ... or if it is a returning customer search the name"). Nothing on any Lavu surface states whether an inbound marketplace ticket populates or matches that customer record. Held unknown rather than no: the ingestion path is a third-party publisher's product, and per merge policy a different publisher's KB does not bound this vendor. Retrieved 2026-09-18. || 328th: 328th: NEW CORPUS, NO MOVE, AND IT EXPLAINS WHY THE 327th'S DOORDASH COUNT WAS CHROME. The 342-article retired Zendesk corpus (census on payments-surcharge-guardrails) predates Lavu's marketplace integrations and its pages carry no site-footer partner links, so it is a clean control for the 327th's finding that 'DoorDash' scores 284 in the current help centre purely as footer chrome: over 1,065,356 chars of retired prose, DoorDash 0, 'Uber Eats' 0, Grubhub 0, 'guest profile' 0. The retired corpus does contain Lavu's native guest identity surface end to end - 'Section 6.7: Customer Management (Gold and Platinum Pro Licenses Only)' plus the frontend walkthrough ('Tap the Customer Management bar. Enter a new customer's information or if it is a returning customer search the name in the search field') - confirming that the native guest profile is created by a server typing the guest in at the register or recalling one by name, with no channel-attach path. Still unknown: nothing in any corpus states what guest identity accompanies a marketplace order into Lavu, and the DSP ingestion contract remains unpublished. Retrieved 2026-09-18. || 330th: MERGE HOLD (proposed partial/B, held unknown): Self-refuting partial. The evidence is two screenshots of a QA tenant: the DSP order carries a marketplace customer id and a test name, the phone is DoorDash's masked relay number on every row, and the POS-side stub has NO customer block (Server: DoorDash). Neither conjunct is met: no native guest profile is shown to receive the order, and the identity is not usable. A marketplace id on a delivery-dispatch record is an adjacent feature. The correction that DSP is Lavu's own spec (not a third-party publisher) stands. PROPOSAL AS WRITTEN: 330th: MOVED unknown -> partial/B. THE 327th HELD THIS BECAUSE 'the ingestion path is a third-party publisher's product'; IT IS NOT - the DSP article is Lavu's own spec of Lavu DSP ('MenuDrive sends the request to Lavu DSP, then Lavu DSP calls the DoorDash API'), and its own screenshots, read as images at full resolution this pass, show what a DoorDash order carries once it lands. WHAT IS SATISFIED: a DX order is NOT anonymous on the MenuDrive side. The order-receipt screenshot https://support.lavu.com/hs-fs/hubfs/dsp37.jpeg (from 'DSP Integration (Delivery Service Provider Integration)') shows 'Online Order 6380' for a DX_DELIVERY ticket headed 'Test T' with 'Customer id: 46530076' beneath the name - i.e. the marketplace order is bound to a MenuDrive customer record id, not dropped as a guestless ticket - and the order-history lists https://support.lavu.com/hs-fs/hubfs/dsp35.jpeg and dsp36.jpeg show every DX_DELIVERY / DX_PICKUP row carrying a guest name and a phone number alongside the DX Code, in the same columns as native TAKEOUT/DELIVERY/DINEIN rows. WHAT SHORTFALLS: (a) the identity is marketplace-masked - the name is a first name plus a last initial ('Test T') and the phone on EVERY DX row in both screenshots is the same (855) 973-1040 DoorDash relay number, while native rows carry distinct local numbers ((314) 555-0055, (697) 353-4503), so the attached identity is not reachable by the operator and no email is shown; (b) on the POS side there is no guest at all - the Lavu POS order stub for a DX order https://support.lavu.com/hs-fs/hubfs/dsp39.jpeg reads 'Call In Order ... Table: DX Delivery ASAP ... Guests: 1 ... Server: DoorDash ... Cashier:' with no customer block, so nothing reaches Lavu's own Customer Management record (the native profile, which the vendor documents as typed in or searched at the register); (c) the article's release note enumerates what DX orders newly display as financial only ('Item Price, Modifier Price, Taxes and Tips'), and no Lavu surface documents matching an inbound DX guest to an existing profile. Not a yes: a differentiator needs the full claim, and a relay number under a truncated name is not 'usable guest identity' the operator can migrate to owned channels. Retrieved 2026-09-18. adversarially verified

Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.

guest-loyalty-accrual-models

Named shortfall: one accrual model only. Points accrue per menu item — items "must have point values pre-assigned" and staff then "Award the points available" at checkout. Redemption offers two "Loyalty Style" options: the discount either "will cost the amount of Loyalty Points" or "will be unlocked at the point threshold". No spend-based, visit-based, category-multiplier or time-boosted accrual is documented, and the award doc states outright that "You cannot award and redeem points within the same transaction". https://support.lavu.com/en/knowledge/creating-lavu-loyalty-discounts · retrieved 2026-08-02

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

guest-loyalty-tiers

A rudimentary status level exists: 'You can also create discounts that provide a permanent discount once a customer reaches a certain number of points', configured by setting Loyalty Points to the threshold and Loyalty Style to unlocked-at-threshold rather than costs-points ('or if it will be unlocked at the point threshold entered for step thirteen (uncommon)'). Shortfalls: promotion is by lifetime accumulated points, not a rolling window of spend or visits; there is no demotion mechanism, no member level or tier entity, and no tier-specific benefits beyond the single attached discount. The MenuDrive loyalty program is separate and has no tier setting at all - its page configures only on/off, title, earn basis (orders or dollars), points per unit, subtotal-or-total, Facebook-like points, terms, and rewards each requiring an attached coupon. https://support.lavu.com/en/knowledge/creating-lavu-loyalty-discounts · retrieved 2026-08-08

Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator

guest-loyalty-offline-behavior

OVERTURNED in part. Lavu Crash Kit 101 does state connectivity behaviour for the gift/loyalty card system, in an explicit list of what survives an outage: 'Conduct cash transactions... Open the cash drawer... Add food and drink to open orders... Start new orders... Send orders to the kitchen... Print checks', followed by 'None of the features above require an internet, or database connection. Most notably what is missing, are credit card and gift card transactions. Both of which require an active connection to the internet to validate card details.' Lavu's loyalty product is Lavu Gift/Loyalty and the documented POS lookup path is the loyalty card number or barcode scan, so redemption against a card is documented as blocked, not queued. Named shortfall: the article never separates loyalty from gift, and it says nothing about what point ACCRUAL does during an outage - whether points earned on an order closed offline are queued and reconciled on reconnect or silently lost is nowhere stated, and none of the loyalty articles (awarding-loyalty-points-and-redeeming-loyalty-discounts, creating-lavu-loyalty-discounts, manage-lavu-gift-and-loyalty-card-balance-and-expiration-date) mentions connectivity at all. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-08 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

Positive absence in a complete configuration enumeration. Marketing - Creating Coupons walks the entire coupon record: enable/disable, coupon code, discount type and amount, validity dates or Never Expires, login requirement, usage limit, a brand-wide limit across MenuDrive accounts, minimum subtotals including a delivery-specific one, public/private, and under Advanced Settings a per-email allow list and a required cart item or category. There is no exclusive-versus-combinable flag and no precedence or order-of-application setting; redemption is by entering one code at checkout, and the loyalty tie-in requires a reward's coupon to be limited to a single use. https://support.lavu.com/en/knowledge/marketing-creating-coupons · retrieved 2026-09-04 adversarially verified

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

Recency-rule targeting is documented: email automations trigger on events such as 'last order' - 'choosing last order and sending a message out with a coupon for a free item after one of your customers hasn't ordered from you for 30 days' - plus birthdays, anniversaries, and sign-ups, with private coupons attachable and coupons restrictable to specific customer email addresses. Shortfalls: no frequency, spend, or items-purchased audience rules, and delivery is email-only. https://support.lavu.com/en/knowledge/marketing-email-automations · 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

Positive absence by enumeration of the targeting model. Marketing - Email Automations documents the whole campaign record - enable, name, subject line, trigger, message body, an optional attached coupon and an active date range - and targeting is an operator-authored event rule, the article's own example being 'choosing last order and sending a message out with a coupon for a free item after one of your customers hasn't ordered from you for 30 days'. No segment object exists, and nothing computes recency/frequency/monetary or lifecycle classes (new, regular, at-risk, lapsed, VIP) on the operator's behalf. https://support.lavu.com/en/knowledge/marketing-email-automations · retrieved 2026-09-04 adversarially verified

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

MenuDrive ships CRM tools and 'email automation' plus a coupon/QR generator; specific birthday, first-visit and lapsed win-back triggers are not named. https://lavu.com/online-ordering/ · retrieved 2026-08-01

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

Native email automation is documented; native SMS campaigning is not. https://lavu.com/online-ordering/ · retrieved 2026-08-01

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

CLAIM: per-channel marketing consent captured with timestamp and source, and revocation honoured by any reasonable means across channels. VERDICT: partial. NEW SURFACE: the live MenuDrive (Lavu's first-party online ordering) guest storefront on order.menudrive.com, reached anonymously through a public storefront (order.menudrive.com/anchorpizzacompany, one of 15,283 storefronts listed in the orderstart.com robots.txt sitemap at prod-menudrive-sitemap.s3.amazonaws.com/sitemap/sitemap.txt). EVIDENCE: the guest Create Account form at https://order.menudrive.com/storefront/my-account/new carries two separate channel checkboxes: '<label class="checkbox-btn">Email me specials <input type="checkbox" value="0" name="email_offer" id="email-subscribe-option" checked>' and '<label class="checkbox-btn">Text me specials <input type="checkbox" name="mobile_text_offer" value="0" id="sms-subscribe-option" checked>'; the legacy form https://order.menudrive.com/customer_signup.php carries the same two fields ('name="email_offer" ... checked', 'name="mobile_text_offer" ... checked'). The storefront's string table adds 'opt_special_email = Please opt for specials email.' and 'opt_special_text = Please opt for special text.' So consent IS captured per channel (email vs text) at the storefront. SHORTFALL: both boxes ship PRE-CHECKED (a default opt-in, not an affirmative act); nothing observed records a consent timestamp or source; nothing documents revocation beyond the form, and the 83-page www.menudrive.com WordPress census (wp/v2/pages 80 + job openings 3) and the prior 250-article support.lavu.com dump say nothing about unsubscribe or revocation. The POS-side Customer Management form (prior note) still shows no consent field. Grade B: a first-party product surface served by the vendor's own host, not marketing. Retrieved 2026-09-16. https://order.menudrive.com/storefront/my-account/new · retrieved 2026-09-16 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

330th: MOVED unknown -> no/B. THIS CLAIM IS DOCUMENTATION-SHAPED ('handles or explicitly documents'), so a publication census can settle it (327th merge rule), and the census is now the CURRENT help centre rather than the retired manual the 328th had to lean on. BOUND: the 245-article support.lavu.com census re-derived this pass from the sitemap (3,150,753 chars of stripped text, every article body), which includes the entire MenuDrive Marketing section - 'Marketing - Email Automations', 'Marketing - Creating Coupons', 'Marketing - Loyalty and Rewards' - plus Lavu Gift/Loyalty and Customer Management. CONTROLS, tokenised, word-boundary, case-insensitive over that census: 10DLC 0, A2P 0, SMS 0, TCPA 0, 'short code' 0, 'text message' 0, texting 0, 'opt-in' 0, Twilio 0, carrier 0. Same controls over the 4,127,475-char Control Panel 3 source corpus: 10DLC 0, A2P 0, SMS 0, twilio 0, smsEnabled 0, textMessage 0. WHAT THE CENSUS POSITIVELY SHOWS: the operator's campaign channel on this platform is EMAIL ONLY - 'Email automations are a free marketing tool that Menu Drive offers to all restaurant owners ... you first need to set up a Mail Server. Fortunately, Menu Drive offers a built in Mail Server that you can use for free ... If you are using your own mail server, or a service like SendGrid, select Custom' - and a campaign is configured as Enable, name, subject line, trigger, message, coupon, active dates. There is no SMS campaign object, no sender/brand/campaign registration screen, and no page anywhere in the corpus that tells an operator what 10DLC is or who registers it, while the platform does put guest text messages on the wire through MenuDrive's carrier-gateway pickup notifications (the 316th's 'Mobile Carrier' select and 'Text me specials' checkbox on order.menudrive.com). So the second limb fails on a census and the first limb has no surface to sit on. POISON, re-published: 'carrier' scores 0 in the help centre but 4 tokenised in the Terms and Conditions / Terms of Service, and all four are 'freight carrier' in the shipping and force-majeure clauses (325th). Retrieved 2026-09-18. https://support.lavu.com/marketing-email-automations · retrieved 2026-09-18 adversarially verified

Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator

guest-loyalty-campaign-attribution

Coupon Reports track per-coupon usage - 'the amount of money your customers have saved by using coupons, and the average discount per order' - and coupons are the redemption vehicle attached to email campaigns and loyalty rewards, so campaign redemptions are countable per coupon code. Shortfalls: no incremental-sales attribution, and redemptions are not tied to actual check totals by campaign in any documented report. https://support.lavu.com/en/knowledge/menu-drive-all-reports · 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 export exists on both sides. In the Lavu Control Panel: 'Once you have captured customer information in the POS, you can export it from your V1 reports. Click on Reports, then V1 Reports, and under the column labeled Special, click on Customer Export' - the profile carries name, address, phone, email and custom fields, and a matching Customer Import accepts CSV. In MenuDrive, the Order History report can be filtered by order type and date and 'download[ed] ... in a PDF or CSV file'. Shortfalls: Customer Management 'will first need to be turned on by a Lavu admin', so the guest list is gated behind a support request; the two exports live in different products and nothing documents an export that joins a guest to their transaction history; the MenuDrive Registered/Guest Customers reports are on-screen tabular views with no stated download; and the public API (api.lavu.com/docs/swagger.json) exposes orders, menus, payments and the API user's own profile but has no guest-list endpoint. https://support.lavu.com/en/knowledge/customer-management · retrieved 2026-08-08

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

A feedback channel exists and is guest-initiated: on the MenuDrive storefront, signed-in customers 'can update their contact information, credit card numbers, and delivery address for faster ordering, provide feedback through their Order History, and redeem loyalty points for discounts.' Shortfalls: nothing triggers a post-transaction request - the only automated guest email documented is the Order Dashboard's ready-time confirmation, and marketing-email-automations' triggers are birthdays, anniversaries, sign-ups and last-order recency, not order completion; there is no score capture, no threshold and no routing, and only registered customers have an Order History to leave feedback in. For public reviews, Lavu's documented method is manual: let-yelp-help teaches the operator to save a Yelp badge image, upload it under Add Footer Image and set the link URL. https://support.lavu.com/en/knowledge/menudrives-online-ordering-storefront-3.0 · retrieved 2026-08-08

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

Positive absence, with the near-miss resolved. Lavu does run a referral program with attribution and rewards, but its terms make it a merchant-acquisition scheme rather than a guest mechanic: participants refer restaurants and bars to Lavu's POS platform, Lavu 'determine[s], in its sole discretion, whether a referral is eligible for a Referral Reward', and the payout schedule sits at go.lavu.com/en-us/refer-and-earn (the marketing page prices it at $2,500 for referring a restaurant). On the guest side, Marketing - Loyalty and Rewards enumerates every program setting - earn by orders placed or by dollars spent, points per dollar on subtotal or total, a Facebook-like bonus, terms text, and rewards defined by title, description, point cost and repeatability - and none of them issues a per-guest referral code, attributes a referred guest's first order, or pays both sides. https://lavu.com/lavu-referral-program-terms-and-conditions/ · retrieved 2026-09-04 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

Positive evidence of a different delivery mechanism. Lavu's digital stored-value path is documented end to end and is an emailed barcode, not a wallet pass: keying 55555 at load time 'will generate a unique 24 digit gift card number that will be sent to the customer's email address', redemption is 'select Scan your card', which 'will turn on your iPad's rear facing camera, allowing to scan the bar code from the customer's email', and re-delivery is a resend from the Control Panel's History & Tracking list. There is no push-updatable balance and no Apple or Google Wallet pass anywhere in the complete 249-article help centre. https://support.lavu.com/en/knowledge/digital-gift-cards · retrieved 2026-09-04 adversarially verified

Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.

guest-loyalty-privacy-rights-tooling

Rudimentary tooling exists: in Customer Management the operator can search a guest by any captured detail and 'if you want to update or remove the information attached to the customer profile, click the Edit button', view their order History, and export the whole guest list from Reports > V1 Reports > Special > Customer Export - which covers the access half of a request by hand. Shortfalls: there is no rights-request workflow, no requester verification, no audit trail and no documented deletion propagation - the POS customer record, MenuDrive registered accounts, Lavu Loyalty point balances and the email-campaign audience are separate stores and no article describes a delete reaching more than the one profile in front of you. Lavu's privacy policy handles requests for Lavu's own data subjects by email/phone and caps CCPA requests at one per customer per year; it gives the operator no in-product tooling. https://support.lavu.com/en/knowledge/customer-management · retrieved 2026-08-08

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

An audit trail is documented: the Control Panel card view shows "every action that has taken place on the card, including creation, loyalty and gift balances used, and manual adjustments", and card histories are "exclusive to the Control Panel for restaurant managers"; on the POS, balance adjustment sits behind the Functions > Manager Functions > Management Tools > Adjust Lavu Card path. Shortfalls: no redemption velocity limits and no flagging of employee self-redemption are documented anywhere, and manual adjustments are gated by menu placement and Control Panel access rather than a documented approval step. https://support.lavu.com/en/knowledge/manage-lavu-gift-and-loyalty-card-balance-and-expiration-date · retrieved 2026-08-03

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

Lavu's own AI feature comparison (February 2026) scores Marty 'AI marketing campaign creation: No' - a vendor statement that offer content is not generated - while the site-wide Marty FAQ claims a timing recommendation: 'Marty spots slow periods. Lavu triggers targeted outreach or bundle suggestions', and the Enterprise plan on buy.lavu.com sells an 'AI Marketing' line. Shortfall: only the send-timing half of the claim is asserted; content and audience generation are denied by the vendor's own comparison; the mechanism is undocumented (MenuDrive's documented campaign engine is rule-based - birthday, anniversary, sign-up and days-since-last-order triggers with operator-written messages); and the feature is quote-only Enterprise. https://lavu.com/2026-restaurant-pos-ai-capabilities-report/ · retrieved 2026-09-02 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

Lavu Gift is a documented first-party stored-value system, not a reseller wrapper: gift card items are sold from the POS via "Issue Card" (fixed or variable amount), redeemed as a payment type by swipe, manual entry or barcode scan, and "If the gift card used does not have a sufficient balance to pay for the order, the remaining balance will automatically be used." The Control Panel Gift & Loyalty Cards page shows "the cards current gift card and loyalty balance" plus "every action that has taken place on the card, including creation, loyalty and gift balances used, and manual adjustments", and an optional expiration date. Shortfall keeping this at partial: balances are keyed to a card ID rather than to a guest profile, and no brand-wide or cross-location redemption is documented anywhere in the Lavu Gift articles. https://support.lavu.com/en/knowledge/lavu-gift-selling-redeeming-gift-cards · retrieved 2026-08-02 adversarially verified

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

Documented two ways, both on the POS terminal with no separate time-clock hardware: from the main POS screen, "Tap the menu button in the bottom left. Tap on Time Clock. Enter your PIN, or Passcode. Tap the clock icon on the PIN pad."; or from the PIN pad screen by tapping the server name then the clock icon. Punches land in the Time Cards report, reachable from End of Day > Manage Time Cards or Workforce > Manage Time Cards. https://support.lavu.com/en/knowledge/pos-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

The punch flow is enumerated: enter PIN or Passcode and tap the clock icon (from Time Clock or the PIN pad screen), then 'complete the popups'; Manage Users documents RFID cards as the alternative credential. No photo capture or facial verification exists at punch anywhere in the labor documentation. https://support.lavu.com/en/knowledge/pos-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

This is Lavu's documented state as of 2019, from its archived Zendesk help centre: 'Offline Order Sync (P2P Mode)' (article dated 8 August 2019; Wayback capture 20 August 2019). Under 'Current Limitations' it says web-based services 'will be unavailable until the internet connection has been restored' and lists 'Clocking in and out' among them. That is an explicit vendor-documented negative: punches cannot be recorded offline, so there is nothing to reconcile on reconnect. The same article says these services 'are currently being worked on' and the list 'will be updated', but no later archived document reports a change: 'Release Note Highlights 2019' (17 October 2019) adds offline support for 50+ devices and the pizza creator and says nothing about the time clock, and the November 2019 Release Notes mention time cards only in an unrelated edit bug fix. The current 250-article help centre is silent on offline punching ('POS - Clocking In and Out' has no connectivity statement), so it neither confirms nor contradicts this 2019 negative. https://web.archive.org/web/20190820211445/https://support.lavu.com/hc/en-us/articles/360026467394-Offline-Order-Sync-P2P-Mode- · retrieved 2026-09-13 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

Named shortfall: permissions resolve to five fixed hierarchical tiers, not per-action grants. "Lavu has five access levels (0-4) that are used to control which features of the application your employees are able to access" — 0 is "restricted to clocking in and out only", 1 servers, 2 floor managers ("access to voids, discounts, refunds, ability to re-open closed orders"), 3 owner/back end, 4 multi-location Control Panel switching only. Manage Users confirms assignment is by tier alone ("Here you will set the access level to your employee"), with no per-user permission checkboxes and no per-location grant. A few functions can be gated to a minimum level in Advanced Settings (PIN use while clocked out, server summary, Management Tools), which is why this is partial rather than a flat absence; void, comp, discount, refund, drawer open and price change cannot be granted independently of the tier. https://support.lavu.com/en/knowledge/lavu-access-levels · retrieved 2026-08-02 adversarially verified

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

Named shortfall: an actor log, not an approval log. The Action Log records "all frontend activity including when orders are opened/closed, when cash drawers are opened, when employees clock in and out, and much more", and the current version supports filtering "to focus on a specific action or employee" — the doc's worked example is finding "which employees conducted refunds". What is not documented is a distinct manager-override event carrying the approver's identity separately from the operator's, nor a required reason code. The legacy V1 report "lacks all of the filtering options that are available in the newer version". https://support.lavu.com/en/knowledge/lavu-reports-the-action-log · retrieved 2026-08-02

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

Help-centre article 'Scheduling' (Lavu Control Panel > Workforce): "Lavu's scheduling platform is a great way to create and manage your employee's schedule. When a schedule is created, your staff can access their schedule online at my.poslavu.com, or you can export your schedule and print it." Documented flow: 'Open the Workforce - Scheduling Module', '+ New Shift', select Employee, select the Class they will work as during the shift, '+ Add Employee', From/To times, 'Click on all of the days the shift will Copy to', 'Add Shift'; plus Actions > Duplicate a previous week / Print / Hide Estimated Pay, and weekly management notes. Publication to staff is native ('have your employees check out my.poslavu.com to see their schedule online and request coverage'), and Workforce Settings carries the matching shift-change notification rules. This is the same Control Panel Workforce section that holds Time Cards, so timekeeping and scheduling are one platform - no third-party scheduling app is required. Earlier rationale relied on a multi-location marketing line about connecting external labor-scheduling platforms; the documentation overrides it. https://support.lavu.com/en/knowledge/scheduling · retrieved 2026-08-08

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

Lavu markets Marty as recommending 'optimal staffing levels for every shift' from 'historical sales data... seasonal trends and local events', with morning briefings that 'recommend necessary staff levels', recommendations 'updated daily', and 'Marty forecasts sales. Lavu generates the schedule with labor control' (site-wide FAQ); the Marty companion app is shipped (App Store, Lavu Inc, June 2026) and the Enterprise plan sells 'Digital General Manager' and 'AI Reporting' lines. Shortfall: marketing-only description with no product documentation - the help centre's Scheduling article shows no recommended-hours output and Workforce Settings lists no forecasting element - daypart granularity is unstated, and Marty is quote-only Enterprise. https://lavu.com/marty-ai-scheduling-recommendations/ · retrieved 2026-09-02 adversarially verified

Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator

labor-realtime-labor-percent

"Management Tools - Live Labor Report" is a documented manager tool, so a real-time labor view exists. Shortfall: the claim is specifically labor cost expressed as a percentage of sales in real time during service, and no Lavu documentation states that the live labor report produces a labor-percent-of-sales figure. https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-02 adversarially verified

Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator

labor-overtime-prevention

Workforce Settings enumerates the labor controls: Overtime Settings 'determine when overtime and/or double-time is paid' (pay calculation only - hours per day, days per week, hours per week), and the documented clock-in restrictions are schedule-window based ('Disallow user from clocking minutes before / after shift') and open-order based. The Overtime report is retrospective. No approaching-overtime warning or block at clock-in exists. https://support.lavu.com/en/knowledge/workforce-settings · 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

Workforce Settings' Employee Breaks section is the entirety of Lavu's documented break configuration and it is a flat tracker: "Set Length of Paid Break to 15 minutes using the dropdown. Set Allow paid breaks every (hours/minutes) to 4 hours by using the first dropdown" — one global break length and one frequency, with no state or jurisdiction dimension, no attestation prompt and no missed-break premium flag anywhere in the enumerated settings (employee classes, overtime thresholds, shift-change notifications, advanced settings, employee breaks). The article then delegates compliance to the operator outright: "Please refer to your local labor laws to understand how this feature should be used." A fully enumerated break feature offering a single global rule, plus the vendor's own instruction that the operator must apply local labor law themselves, is positive evidence that the jurisdiction-aware rules, attestation and premium-pay flagging the claim describes are absent. https://support.lavu.com/en/knowledge/workforce-settings · retrieved 2026-08-04

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

labor-minor-labor-rules

VERDICT moved to no. The prior pass had the help-centre article's section list; it now has the shipped setting list, which is the enumeration the article was summarising. NEW SURFACE: the Control Panel 3 SPA (prod-cp3-01.aws2.poslavu.com) publishes source maps for 99 of its 100 webpack chunks - 2,217 first-party source files, 4.76 MB of `sourcesContent` - and `modules/cp3-workforce/Settings/locales/en.js` is the complete English string table for the Workforce Settings screen. Its sections and every field in them are: Employee classes (class name, front/back of house, tip out rules), Overtime settings ('Work week ranges from', 'Calculate day rollover at', 'Overtime applies after', 'Double time applies after', 'Overtime / double time applies to the following holidays (US only)', 'Exclude overtime hours from regular hours worked'), Shift change notifications (email preferences for trades requested/accepted/revoked), and Advanced settings ('Manage advanced user permissions and clock punch settings': 'Employee clocking in becomes active server', 'Prevent servers from clocking out when they have open orders', 'Ask server to clock out after printing Server Summary', 'Auto exit server upon employee clock out', 'Block users from clocking minutes before/after shift', 'Access level for which to block PIN usage when user is clocked out'). There is no age, birth-date, minor, school-day or prohibited-hours dimension in the settings, in the shift creator (`Scheduling/Modals/NewShift/*` takes day buttons, employees, class and shift hours only) or in the clock-in path. BOUND/CONTROLS over the whole 4.76 MB corpus, tokenised word-boundary, case-insensitive: `age` 0, `school` 0, `juvenile` 0, `child labor` 0, `date of birth` 0, `birthdate` 0, `dob` 0. POISON NAMED: `minor` scores exactly 1 and it is the country-list entry 'UM: United States Minor Outlying Islands' in the inventory locale - a bare substring grep would have reported a hit. Related and consistent: the same product's break settings explicitly push jurisdiction compliance onto the operator ('Es responsabilidad exclusiva del operador del restaurante verificar que su politica de descanso cumpla con las leyes laborales especificas de su jurisdiccion'). Bound: the Lavu Control Panel workforce module, the only place Lavu schedules or clocks employees, plus the 245-article help centre re-fetched 2026-09-17 where `minor` occurs once, in the phrase 'minor adjustments'. Retrieved 2026-09-17. https://support.lavu.com/en/knowledge/workforce-settings · retrieved 2026-09-17 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

Rules are configurable and computed by the system, not by spreadsheet. Tip pooling is enabled per employee class ("Use tip pooling in this employee class") and split either evenly among clocked-in class members or by "Hours worked"; the pool period is Shift (split at a configured "Shift change occurs" time), Daily, or Weekly with a configurable work-week start. Tip Out pushes a configurable percentage of tips or of sales from one class to other classes, with multiple recipient classes splitting the designated percentage and the calculation source selectable as total, cash-only or card-only tips, or total or super-group sales. Tip Withholding deducts a percentage of credit-card tips for processing cost. Points-based allocation is not offered; the claim lists percentage of sales, hours worked, points or role, and Lavu satisfies three of the four. https://support.lavu.com/en/knowledge/workforce-settings · retrieved 2026-08-02 adversarially verified

Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.

labor-tip-distribution-audit-trail

Per-employee tip records are documented and exportable — Time Card Reports track "tip and gratuity collection" with tips and gratuity carried in all five export options — and Workforce Settings documents the pool computation itself (pooling per employee class, split evenly or by hours worked over shift/daily/weekly periods; class-to-class tip outs by percentage; credit-card tip withholding). Shortfall: no documented report itemises, per shift and per employee, the amounts contributed to the pool versus distributed from it — Tip Engine V2 surfaces only a "Net Tips" figure on the server summary, so the pool-side ledger the claim requires is not documented. https://support.lavu.com/en/knowledge/time-card-reports · 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

Lavu Payroll is native and the Run Payroll flow does separate tip channels per employee: "Next to Paycheck Tips, enter the amount of tips that are paid to your employees directly on their paycheck ... Next to Cash Tips, enter the amount of tips your employee has received in cash. This includes any credit card tips the employee is cashed out at the end of each shift", with an instruction to account for gratuity and tip-outs/tip-pooling. Lavu also issues W-2s (Onboarding Your Employees into Lavu Payroll: information must be accurate 'so that there are no issues in receiving pay checks, or their W-2 in the first quarter of the new year'). SHORTFALLS, all three: (1) the split is a manual per-period entry field, not a machine-carried designation - it is cash-received vs paid-on-paycheck, not a 'qualified tip' classification; (2) no Treasury tipped-occupation code field appears anywhere in the payroll, employee-profile or Workforce Settings articles (Employee Classes carry only a name and FOH/BOH, which the doc says 'will have no affect on your employee profiles'); (3) the 250-article help centre contains no reference to W-2 Box 12 code TP or Box 14b, and no payroll-export field list. Retrieved from the 250-article support.lavu.com dump 2026-08-08. https://support.lavu.com/en/knowledge/how-to-run-payroll · retrieved 2026-08-08

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

Lavu markets Payroll as its own product with payroll specialists and automated runs, and its blog describes EFTPS tax deposits and Forms 940/941. Shortfall: the claim requires Lavu itself to be the filing agent and to remit direct deposit; no first-party source states whether Lavu files and remits or white-labels a provider, there is no payroll article in the support knowledge base, and payroll is not a monitored status component. https://lavu.com/payroll/ · retrieved 2026-08-02 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

QuickBooks (with payroll) and Restaurant365 workforce are named integrations; Gusto, ADP, Paychex and Paylocity are not listed. https://lavu.com/integrations/ · retrieved 2026-08-01

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 can self-service 'request shift coverages' through my.poslavu.com when using Lavu's scheduling platform, and Shift Change Notifications settings control whether and which managers (levels 2-3, or 2-4 on chained accounts) receive those emails. Shortfalls: no documented approval workflow - the mechanism is email notification - and no overtime or role-eligibility enforcement on the swap. https://support.lavu.com/en/knowledge/workforce-settings · retrieved 2026-08-05

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

Per-employee sales exist: the Cashier Sales report "will show you a breakdown of users who have closed orders, including card totals, cash sales, tips, gratuity, and more", exportable, and the printed Server Summary "reflects sales and transaction data conducted by the specific user". Void and discount attribution exist: the Voided Items report shows "the cashier associated with the order, which is likely the same person that voided the item", and the Discount report is filterable by "Order Server" or "Order Cashier" with a Check Discounts List "broken down by Order ID, Server, Cashier, Discount, and Total Amount". Shortfall: no report publishes an average check per server, an items or category attachment rate, or a void/comp rate as a rate rather than a list - the manager has to derive them from exports. https://support.lavu.com/en/knowledge/lavu-reports-cashier-sales · retrieved 2026-08-09 adversarially verified

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

Documented ingredient-level bill of materials per menu item: on the menu item there is a box labelled Ingredients where "you will be able to add your ingredients from the drop down menu, and designate how much of that ingredient is used in one serving of this menu item." Costing basis is operator-selectable in Inventory Settings between "Average Costing (Periodic)" and "FIFO (First In, First Out)", which "dictate how the Food and Beverage report tabulates cost of goods sold". https://support.lavu.com/en/knowledge/inventory-link-ingredients-to-menu-items · retrieved 2026-08-02

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

Named shortfall: units convert, yields do not. Inventory Settings ships default units of weight and volume ("Several units of weight and volume are created for your account by default") and supports operator-defined composite units — the doc's example is "Dozen, which contain 12 units". Each item carries distinct "Purchase/Sales Unit(s)", and the two alert types key off different units (low stock on Purchase Units, 86 count on Sales Units). What is absent from the documentation is any raw-to-prepared yield percentage, trim loss factor or cooked-weight conversion, so recipe cost is computed on as-purchased quantity. https://support.lavu.com/en/knowledge/inventory-settings · retrieved 2026-08-02

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

A variance comparison exists and is documented: "To update your stock, simple type in the number under the Count column ... When you are finished, click the green reconcile button ... Once this is done, you can navigate to your inventory reports, and click on Variance to see your recently saved changes. This can help you track the variance of a particular item from week to week, or month to month." The counted figure is compared against system stock that is genuinely theoretical - ingredients are linked to menu items and 'the system can deduct from item stock with each sale' (Inventory Import and Export), receipts come in through Purchase Orders and out-of-PO Receive, and waste is decremented with reasons (Inventory Settings). Costing is present too: Inventory Settings offers Average (Periodic) or FIFO, which 'will dictate how the Food and Beverage report tabulates cost of goods sold'. SHORTFALLS: the Variance report is documented in a single sentence with no column list - nothing states that it presents theoretical usage and actual usage as separate figures, and nothing states the variance is expressed in currency as well as units. The Inventory Dashboard panel enumeration (Low Stock Level, Inventory Value, Pending Transfers, Waste Summary, Purchase Order Summary, Use First) contains no variance tile. Checked against the full 250-article support.lavu.com dump, 2026-08-08. https://support.lavu.com/en/knowledge/inventory-reconciliation · retrieved 2026-08-08

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

inventory-realtime-depletion

Depletion is automatic and on-sale, not batch: ingredients carry a per-serving quantity on the menu item, and "whenever the item is sold, stock automatically be deducted from your inventory". Shortfall: the claim requires depletion driven by modifier selections, and the article attaches ingredients only to menu items — modifiers are never named as an ingredient host, so add-ons under-deplete. https://support.lavu.com/en/knowledge/inventory-link-ingredients-to-menu-items · 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

All three channels documented. POS: setting "Track 86 countdown" to "Track by Inventory Item Level" means "when the inventory stock level is too low, the menu item it is attached to will grey out, and it will not be able to be added to any orders." Third-party: "If an item is out of stock on the POS, then the item will automatically be removed from the DoorDash storefront", explicitly "whether you are using Item Level 86 Tracking, or Lavu’s inventory platform with ingredients." Online ordering carries its own "Item 86 Count Tracking in Menu Drive" article. https://support.lavu.com/en/knowledge/lavu-menu-drive-and-door-dash · retrieved 2026-08-02 adversarially verified

Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.

inventory-count-modes

Named shortfall: adjustments yes, count sessions no. The Manage tab supports two documented stock adjustments — Waste Items (item, quantity and waste reason queued to a "Pending Item" list then saved) and Receive Items (item, cost per unit, quantity, unit of purchase) for stock arriving outside a purchase order — and ingredients can be bulk loaded by CSV import. No count sheet, blind count, cycle-count schedule or count-session variance posting is documented anywhere in the inventory articles. https://support.lavu.com/en/knowledge/inventory-manage-tab · retrieved 2026-08-02

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

VERDICT moved to no. Two new, independent bounds, and between them every conjunct of the claim fails. (1) A CLOSED ENUMERATION OF WHAT LAVU'S SCANNER IS FOR. support.lavu.com/en/knowledge/lavus-camera-scanner - re-fetched 2026-09-17 from the 245-article sitemap - states: 'The Lavu POS is able to use the iPad's built in camera to scan bar codes to perform a number of actions:' followed by exactly three bullets - 'Ring items up and add them to your order', 'Accept payments through Lavu Gift', 'Accept Lavu Loyalty numbers (physical cards only, and uncommon)' - with the qualifier 'Each of these actions require other settings to be enabled, like Lavu Gift integration and UPC codes to be entered on the menu.' Inventory counting is not among the three. That also disposes of the vocabulary objection: barcode scanning IS a Lavu product with its own article, so its absence from counting is a fact about the product and not a gap in my search terms. (2) THE SHIPPED COUNTING MODULE. The Control Panel 3 SPA served from prod-cp3-01.aws2.poslavu.com ships 99 of its 100 webpack chunks with public source maps, 2,217 first-party source files, 4.76 MB of `sourcesContent` (corpus retained at .cache/q323/lavu). Its inventory module `modules/cp3-inventory-new` (745,814 bytes, 60+ files) is the counting product, and it is a browser Apollo/GraphQL screen: `views/Counting/components/CountingModal/*`, `graphql/queries/counting.js`, `graphql/mutations/counting.js`, and a locale file that enumerates the whole UI - 'Full cycle count', 'Partial Cycle', 'Save & close count', 'Submit', 'Print count', columns Name / Units of measure, 'There is no ingredient count data for this location. Please create a count.' CONTROLS over those 745,814 bytes, tokenised: `barcode` 0, `scan` 0, `qr` 0, `offline` 0, `indexedDB` 0, `service worker` 0. POISON NAMED: `UPC` scores 144 inside the inventory module but it is a stored INGREDIENT FIELD rendered as text (`IngredientNameCell`: ``if (upc) { upcValue = `UPC: ${upc}` }``), not a scan input - a bare `upc` grep would have manufactured a yes; and across the whole 4.76 MB corpus a substring grep for `scan` scores 15 while a tokenised one scores 0 - the 15 break down as descanso/descansos/Descanso 10 (Spanish for break/rest, in the timecard locale), buscando 2 (Spanish for looking-for), and the camelCase identifier voidMultipleOrder**sCan**tBeVoided 3. Three different words, none of them scanning: exactly the `nest`-inside-`honest` trap. Bound: the CP3 web Control Panel is the only counting surface Lavu ships or documents; the 245-article help centre likewise puts every inventory entry point in the browser Control Panel. Retrieved 2026-09-17. https://support.lavu.com/en/knowledge/lavus-camera-scanner · retrieved 2026-09-17 adversarially verified

Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator

inventory-vendor-catalogs-edi

Positive evidence of absence, re-read verbatim: "Lavu Inventory does not have the ability to contact your vendors. Lavu will not send emails or contact your vendors in any way." A vendor record needs only "the name and the email address of the vendor. All other information is optional" — no catalog, no price file, no transmission path. Receiving is manual quantity entry closing the order as "Closed" or "Partial". https://support.lavu.com/en/knowledge/inventory-vendors · retrieved 2026-08-02 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

Positive evidence that manual line entry is the only path. Inventory: Vendors documents the entire vendor and purchasing flow: a vendor record requires only a name and email address, orders are built by 'selecting items you want to order, and how much you are ordering', and receiving is 'Type in the amount for each ingredient that you received and click Receive'. The article also states flatly that 'Lavu Inventory does not have the ability to contact your vendors. Lavu will not send emails or contact your vendors in any way', so no invoice reaches the system by email, and no photo or PDF ingestion appears anywhere in the Inventory category. Sourcery, Lavu's AP-automation brand still named in the Terms of Service and the privacy policy, has no remaining product surface - getsourcery.com 301s to lavu.com and 'sourcery' appears in zero of the 4,844 first-party sitemap URLs. https://support.lavu.com/en/knowledge/inventory-vendors · retrieved 2026-09-04 adversarially verified

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

Positive evidence of absence by enumeration: the alerts article describes exactly two alert types — "Low Stock Alerts" (purchase units, Control Panel dashboard) and "86 Count alerts" (sales units, surfaced on the POS, with "real time iPad notifications when selected menu items are low in stock"). No cost-variance, vendor-price-increase or other price-based alert appears in the enumerated set, and no email delivery is offered. https://support.lavu.com/en/knowledge/inventory-alerts-in-lavu · retrieved 2026-08-02 adversarially verified

Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator

inventory-par-auto-suggest

Threshold half is documented: item details expose 'Item Name, Primary Vendor, 86 Count, Low Stock Alert, Category, Location, BIN, Serial Number, SKU, and Purchase/Sales Unit(s)' (Inventory Manage Tab), Inventory Alerts in Lavu explains 'Low stock alerts are triggered once the current stock level, in terms of Purchase Units, is lower than the threshold marked for an ingredient', and the Inventory Dashboard's Low Stock Level tile is 'A running count of items that are at or below their Low Stock Alert value ... Clicking the Low Stock Level tile will direct you to a filtered view of the Manage tab, displaying only inventory items at risk of depletion.' SHORTFALLS: (1) no suggested order quantity - Inventory: Vendors walks the whole ordering flow and it is manual, 'select the vendor you want to order from to start. Then start selecting items you want to order, and how much you are ordering'; nothing pre-fills par minus on-hand; (2) no forecast-driven mode at all - the string 'forecast' occurs zero times in the 250-article support.lavu.com corpus; (3) the item-detail field list contains no par level as such, only the alert threshold. Retrieved 2026-08-08. https://support.lavu.com/en/knowledge/inventory-manage-tab · retrieved 2026-08-08

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

inventory-waste-logging

First-class waste workflow with reason codes: "Waste Reasons are the specific, predefined causes that indicate why part of an item's stock had to be discarded", preloaded with Damage, Spoilage and Mismade and extensible. Waste is entered from the Manage tab (item, quantity, reason, queued then saved) and rolls up on the Inventory Dashboard as the "total value of wasted inventory items for the current and previous day's business". https://support.lavu.com/en/knowledge/inventory-settings · retrieved 2026-08-02

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

Named shortfall: age-based, not date-based. The Use First Inventory panel tracks perishables by category and age, surfacing stock "that have been in inventory for Y days" so older stock is consumed first, and "Use First" is a named settings group. There is no per-lot expiry date field, no expiry alert and no automatic block on selling expired stock — the Manage tab item fields are Item Name, Primary Vendor, 86 Count, Low Stock Alert, Category, Location, BIN, Serial Number, SKU and Purchase/Sales Unit(s), with no expiry among them. https://support.lavu.com/en/knowledge/inventory-dashboard · retrieved 2026-08-02

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

inventory-bar-partial-bottle

Achieved via partners, not natively: Bar-i Liquid Accounting (weight-based liquid inventory) and Digital Pour (tap metrics) are listed integrations. https://lavu.com/integrations/ · retrieved 2026-08-01

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

Named shortfall: COGS is computed, GL mapping is not documented. The operator selects a costing method — "Average Costing (Periodic)" or "FIFO (First In, First Out)" — which "dictate how the Food and Beverage report tabulates cost of goods sold", and Control Panel reports export to .txt, .xls and .csv. What no article documents is assigning inventory categories to general-ledger account codes, so posting to QuickBooks/Xero/Restaurant365 still depends on the third-party connector doing the mapping. https://support.lavu.com/en/knowledge/inventory-settings · retrieved 2026-08-02

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

First-party inventory with first-party costing. Lavu Inventory Settings offers two selectable costing methods — "Average Costing (Periodic)" ("cost of goods sold will be calculated based on the average of all purchase costs/unit for a given item’s stock over the selected period") and "FIFO (First In, First Out)" — plus units of measure, storage locations, waste reasons and "Use First" perishable handling. The Inventory Dashboard reports Inventory Value, waste value for current and previous business day, and Expected Receivables. MarketMan, Restaurant365 and Bar-i extend this rather than supply it. https://support.lavu.com/en/knowledge/inventory-settings · retrieved 2026-08-02 adversarially verified

Joins recipe cost to actual item sales mix to report contribution margin per menu item, and flags items whose margin fell below a configured threshold after ingredient cost changes. differentiator

inventory-menu-margin-linkage

The recipe-cost-to-sales join is documented and real: after ingredients are attached to menu items and super groups are typed FOOD or LIQUOR, "whenever sales are made, the cost of creating that menu item from your ingredients will be calculated against the price of the menu item, to give you a cost percentage of either Food or Liquor depending on your settings", viewed under End of Day > Overview v2. Costing method is configurable (Average Periodic or FIFO) and 'will dictate how the Food and Beverage report tabulates cost of goods sold' (Inventory Settings). SHORTFALLS: (1) the output is a cost percentage aggregated to the FOOD/LIQUOR super-group type, not contribution margin per menu item - Lavu Reports - Sales by Item reports item sales but is not documented as carrying ingredient cost or margin; (2) no margin-threshold flag or alert of any kind is documented - the only inventory alerts are Low Stock and 86 Count, which are stock thresholds; (3) nothing re-evaluates margin after an ingredient cost change. Checked against the full 250-article support.lavu.com dump, 2026-08-08; the Marty 'profit leak identification' line on lavu.com is grade D and was not relied on. https://support.lavu.com/en/knowledge/tracking-food-liquor-costs · retrieved 2026-08-08

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

Cloud reporting with mobile access is marketed, plus a Marty-generated "Morning Deposit" digest. Shortfall: the claim requires transactions reflected within minutes and access from both a browser and a mobile app off-premise; no Lavu source states a refresh interval, and no separate manager reporting app is published alongside the POS and KDS iOS clients. https://lavu.com/compare-lavu/ · 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

Documented "Manager Functions - X and Z Report" plus "Management Tools - Shifts". https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-01 adversarially verified

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: "The Sales by Item report will automatically break down your sales report by individual items sold ... Sales by item are broken down by item total, modifiers, subtotal, etc. It can also be broken down by individual cashiers", exportable to txt/xls/csv with bar and pie charts. Modifier level: a separate report exists - "Modifier Usage breaks down the activity of forced and optional modifiers. You can think of it like a sales report but for you modifiers ... Modifiers are broken down by quantity and cost ... Forced modifiers are displayed at the top of the report. Scroll down to see the Optional Modifier usage report." Daypart filtering is documented: 'A single day can also be filtered by the Start Time and End Time you would like to view. For example, you can view all sales on Tuesday that occurred from 1:00 p.m. to 5:00 p.m.' (Lavu Reports - Using Filters). SHORTFALLS: (1) modifier-level product mix lives in a separate report expressed as quantity and cost, not gross and net sales alongside the item; (2) neither article documents a revenue-center filter - Revenue Centers are described as letting you 'compare sales from different areas of your restaurant' between service layouts or tables, but no report page is documented as filterable by them; (3) no article states that Sales by Item distinguishes gross from net (post-discount) sales. Checked against the full 250-article support.lavu.com dump, 2026-08-08. https://support.lavu.com/en/knowledge/lavu-reports-sales-by-item · retrieved 2026-08-08

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

Named shortfall: attribution yes, reason codes no. The Discount Report shows "which discounts were applied to orders, including when they were applied, who applied them, and how much was discounted", and the Action Log adds per-employee filtering across order open/close, drawer opens and refunds. No documented void/comp reason-code taxonomy, and no approver-vs-actor distinction. Upgraded from a marketing-page citation to first-party report documentation. https://support.lavu.com/en/knowledge/lavu-reports-the-action-log · retrieved 2026-08-02

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

Documented "Management Tools - Cash Reconciliation", "Management Tools - Vault Management", "Register Functions - Paid In / Paid Out", "POS - Tilling In and Out". https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-01 adversarially verified

Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.

reporting-labor-productivity

Labor is a reportable dimension alongside sales; sales-per-labor-hour and labor % by hour/department/employee are not documented. https://lavu.com/restaurant-pos/multi-location · retrieved 2026-08-01

Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator

reporting-server-scorecards

"Manager Handbook: Server Summaries" is a documented manager function. Shortfall: the claim requires per-server average check, items per check, attachment rate for named categories, and tips as a percentage of sales; the metric set is not enumerated in any retrievable Lavu source. https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-02 adversarially verified

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 slicing by channel exists: Revenue Centers compare sales across the service layouts (Quick Serve, Tables, Tabs) and even individual tables, Order Types (Dine In, Pickup, Carry Out, custom) tag every order for reports, and DoorDash/MenuDrive orders carry per-order financial detail into MD reports and the POS. Shortfalls: no margin reporting net of marketplace commission - DoorDash fees never appear in any Lavu report - and no consolidated per-channel profitability view. https://support.lavu.com/en/knowledge/revenue-centers · 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 delivery exists, but only in MenuDrive: "Automated reports are a way you can have Menu Drive reports sent directly to your email ... Start by logging into your Admin Control Panel, click on Reports, and then click on Report Settings. The first section allows you to determine who will receive this report. Simply add their email addresses to the list. You can add as many people as you want ... Next you will need to create your 'close of business day rules'. This determines when your report will be sent ... Select the day of the week, and the time you wish the report to be sent. You can set as many of these as you want." SHORTFALLS: (1) the claim asks for ANY report to be schedulable - this is a single fixed report, self-described as 'a very high level report, detailing your sales, payments, discounts redeemed, what was collected in tips, and more'; (2) it covers MenuDrive online ordering only, not the Lavu POS Control Panel, whose reporting is documented as pull-only ('All four categories can be exported to a .txt file, a .xls file, and a .csv file' after setting a date range); (3) no shared destination (SFTP/drive) is offered, email only; (4) the cadence is quirky - 'the report will include information since the last time the report was sent'. Checked against the full 250-article support.lavu.com dump, 2026-08-08. https://support.lavu.com/en/knowledge/how-to-set-up-automated-reports-in-menudrive · retrieved 2026-08-08

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

Confirmed independently: api.lavu.com presents only an API-portal shell with Swagger (JSON/YAML) and ReDoc links plus a Login link; no auth model, no rate limits, no sandbox, no endpoint reference without credentials. Lavu's integrations page does add a first-party marketing hook — "Need something different? Try our open API!" — and the multi-location page repeats "Open API", but neither yields a public reference. Partner-gated is the right read. https://api.lavu.com/ · retrieved 2026-08-01 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

328th: MOVED unknown -> no. THE SPECIFIC DEFECT THE 2026-08-08 DOWNGRADE NAMED IS GONE: it said Lavu's legacy integration document at admin.poslavu.com/cp/areas/api_doc.html is 'a partner-gated document [and] by definition not an enumeration a verifier can read to the end'. IT IS NOT GATED. It was fetched anonymously in the 325th and re-fetched in full today: HTTP 200, 23,117 B, no login, no key (nonsense control https://admin.poslavu.com/cp/areas/zzq-nonsense-q328.html = HTTP 404, 229 B, so the 200 is not a catch-all). It IS a closed enumeration and it was read end to end. It declares the whole interface: 'API URL: https://admin.poslavu.com/cp/reqserv', a complete POST-variable list - 'dataname (required), key (required), token (required), table (required), column, value, value_min, value_max, limit' - and a complete table list - 'Available Tables: menu_groups, menu_categories, menu_items, tables, orders, order_contents, order_payments, ingredients, ingredient_usage' - followed by the full column dump of each and worked PHP/C# examples for query and for `cmd=insert&table=order_payments`. There is no callback URL, no subscription, no event and no delivery semantics anywhere in it: webhook 0, callback 0, notify 0, subscribe 0, postback 0, HMAC 0 over all 23,117 bytes; the two 'signature' hits are the order_payments column of that name. Lavu's other published interface, api.lavu.com/docs/swagger.json (72,254 B, re-fetched today, 200), has 26 paths and none of them registers an endpoint. Both of Lavu's published API documents are therefore now readable to the end and neither offers outbound event delivery, let alone documented retry behaviour or payload signature verification. Corroboration: `webhook` scores 0 over the 1,818-file CP3 Control Panel source corpus, 0 over the current 249-article help centre and 0 over the 342-article retired Zendesk corpus recovered this pass (1,065,356 chars; census described on payments-surcharge-guardrails). CONTESTABLE POINT, STATED PLAINLY: the 327th's merge rule holds a webhooks `no` when a vendor runs an UNPUBLISHED partner API. Lavu's is published - two documents, both anonymous, both complete - which is why I am proposing the move rather than another hold. Retrieved 2026-09-18. https://admin.poslavu.com/cp/areas/api_doc.html · retrieved 2026-09-18 adversarially verified

API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator

reporting-api-not-upcharged

The purchase gateway prices every add-on module individually (Kitchen Display $29, Payroll $39, Reservations $19, Marketing $25, Inventory $29, Gift Cards $15, Loyalty $19, Customer Display $12, Employee Scheduling $22) and lists no API or data-access SKU; the plan catalogue at buy.lavu.com/api/plans lists none either; the Terms of Service fee section names subscription fees, the MenuDrive revenue share and LavuCare only; report export to txt/xls/csv is documented with no fee; and lavu.com/restaurant-pos/multi-location markets 'Open API for integrations' as a standard feature. Shortfall: API credentials are issued rather than self-served (api_posture: partner-gated), no page states that API access is included in Starter or Growth, and the Enterprise feature list is expressly open-ended ('include, but are not limited to'). https://buy.lavu.com/api/addons · retrieved 2026-09-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

Lavu's self-serve purchase gateway publishes three plans: Starter $0/mo and Growth $79/mo each list only 'Core POS' (plus one terminal or custom hardware, 24/7 support, 'Add-ons available'), while 'Advanced Analytics' and 'AI Reporting' appear only under the quote-only Enterprise plan ('You select the features that fit your needs'). The Control Panel reports the help centre documents - Summary, Sales by Item, Modifier Usage, Voided Orders/Items, Discounts, Overtime, Live Labor Report - carry no tier notice, so labor-vs-sales, PMIX and comps/voids appear to sit on the base product. Shortfall: multi-location comparison needs the Multi Location Menu Management / Enterprise Management extension, 'Advanced Analytics' is Enterprise-only, and Lavu publishes no feature-by-tier matrix saying where 'Core POS' reporting ends. https://buy.lavu.com/api/plans · retrieved 2026-09-02 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

Positive evidence of absence in the contract, twice over. No retention window of any length is published for the reporting UI, and the Terms of Service reserve the opposite right: Lavu may 'suspend or terminate your User Account, revoke your Software License ... and delete all data associated with your User Account without prior notice if there has been no Account Activity in your User Account for a period of 180 days', where Account Activity is itself defined on a rolling 30-day basis (payments, orders or clock punches recorded in the last 30 days). The Lavu Terms and Conditions add that on termination 'Lavu has no obligation to retain, provide access to, or allow extraction of User Content or User Data' and 'may delete all User Content and User Data immediately'. A 24-month queryable window is therefore not merely unpublished but contractually disclaimed. https://www.menudrive.com/terms/ · retrieved 2026-09-04 adversarially verified

Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator

reporting-anomaly-alerts

Marty 'surfaces margin leaks, labor inefficiencies, and revenue trends' and flags underperforming sites 'before month-end reports'; operator-configurable thresholds are not documented. https://lavu.com/restaurant-pos/multi-location · retrieved 2026-08-01

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

Lavu ships 'MARTY - AI Companion' (seller Lavu Inc, v1.0.21, June 2026) on the App Store, described as 'an AI-enhanced analytics companion... going beyond manual reporting to predict trends', with release notes that reference 'the chat feature'; Lavu's own February-2026 feature comparison (lavu.com/2026-restaurant-pos-ai-capabilities-report/) scores Marty 'Chat AI (natural language Q&A): Yes', and its site-wide Marty FAQ invites operators to 'Hit us on Marty Chat'. Shortfall: Marty is sold only under the quote-only Enterprise plan ('AI Reporting' on buy.lavu.com/api/plans); no documentation shows a question against the operator's own sales or labor data returning a figure or chart; Lavu's comparison marks 'In-chat task execution: No' and describes Marty's core output as an overnight push briefing rather than answers to ad-hoc questions; and 'Marty' appears nowhere in the 250-article help centre. https://apps.apple.com/us/app/marty-ai-companion/id6752260419 · retrieved 2026-09-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 are documented for online-ordering customers: the Registered Customers report shows 'how many times they have placed orders, the average bill, the total amount they have spent, and the date of their last order' (Guest Customers mirrors it for unregistered guests), and POS Customer Management keeps per-customer order history. Shortfalls: no new-vs-returning counts, no lifetime-spend cohort groupings, and coverage is limited to MenuDrive/Customer Management records rather than all guests. https://support.lavu.com/en/knowledge/menu-drive-all-reports · 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

Lavu's Marty AI marketing states 'Marty analyzes your restaurant's historical sales data. It considers seasonal trends and local events. This intelligence predicts future demand', that morning briefings 'outline predicted sales for the day', and - in the FAQ block Lavu repeats site-wide - 'Marty forecasts sales. Lavu generates the schedule with labor control'; the Marty companion app shipped on the App Store in June 2026 (Lavu Inc, v1.0.21). Shortfall: the forecast is described only at whole-day granularity inside a briefing, not at daypart or hourly resolution in a reporting UI; consumption by scheduling is asserted in marketing, not documented; Marty is available only on the quote-only Enterprise plan; and 'forecast' occurs zero times in the 250-article help centre. https://lavu.com/marty-ai-scheduling-recommendations/ · retrieved 2026-09-02 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 and charged tips are both captured per employee: Advanced Location Settings - Reports documents a prompt "to have servers enter cash tips before printing their Server Summary" plus a "Server Cash Tips Record Mode" dropdown and tip-out entry prompts; the End of Day - Tips & CC Batching page shows editable per-server "Card Tips" and "Cash Tips" columns reviewable until batch settlement; and Time Card Reports carry tips and gratuity in all five export options, two of them formatted to "make it easier to upload into your payroll software". Shortfalls: no documented report itemises tip-pool contribution versus distribution per employee — Tip Engine V2 surfaces only "Net Tips" on the server summary even though Workforce Settings computes pools and tip-outs — and no tax liability summary by jurisdiction is documented anywhere in the reporting suite. https://support.lavu.com/en/knowledge/advanced-location-settings-reports · retrieved 2026-08-04

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

Named shortfall: two levels, no region or brand tier. MLMM runs on an "umbrella configuration" in which "one or more primary locations can be configured for a chain of locations. The menu can be managed from a primary to non-primary locations." Access level 4 lets a multi-location owner switch locations without re-login. There is no documented region, district, group or brand object between the umbrella and the location, so policy and reporting roll-ups above the location level are limited to the whole set. https://support.lavu.com/en/knowledge/multi-location-menu-management · retrieved 2026-08-02

A corporate-level menu can be authored once and published to a chosen set of locations in a single action, with a publish/version history showing what was pushed, when, and by whom.

multi-location-central-menu-publish

Multi-Location Menu Management publishes from a primary location: "Menu can be updated quickly and managed to multiple locations in a single action." Two documented modes — a full sync that replaces the target menu, and an incremental sync where "changes are updated in the target location without altering any items that were added specifically to the target location(s) beforehand. This means you can have location-specific items." https://support.lavu.com/en/knowledge/multi-location-menu-management · retrieved 2026-08-02

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

Named shortfall: propagation from a primary, not a named zone object. MLMM offers a bulk price update that can "update the prices of your menu items, modifiers, or both simultaneously" at the primary location and then sync that to selected targets, and incremental sync preserves location-specific overrides. But there is no price-zone or price-band entity to which a set of locations is assigned; grouping is expressed only as which targets an operator picks for a given sync. https://support.lavu.com/en/knowledge/multi-location-menu-management · retrieved 2026-08-02

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

"Per-location and consolidated reporting... roll it up into a group view" covering sales, labor, voids and comps. Shortfall: the claim also requires store-vs-store ranking and variance flags, neither of which is documented; evidence remains a vendor marketing page with no supporting help-centre article for an above-store reporting view. https://lavu.com/restaurant-pos/multi-location · 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

From Lavu's archived Zendesk help centre, 'NEW! Lavu Gift Card Overview / Adding Cards as Menu Items' (article dated 23 June 2017; Wayback capture 19 August 2019). Its Gift Card Program Features list says 'Cards can be loaded and used across chain locations', for the Lavu Gift extension that Lavu Sales activates. A 'chain' in Lavu is built with Configure Chains, which the archived Section 4.8 describes as letting 'an account holder for multiple locations' link their stores, so this establishes cross-location redemption within one account holder's chain. It is partial because no archived or current article documents an outstanding gift-card liability figure or any settlement or reconciliation of redemptions between separately owned stores. A January 2019 release-note bug fix only shows that a Lavu Gift/Loyalty Report could be scoped to 'All Locations'. This is the 2017-2019 archived state; the current help centre neither repeats nor contradicts the cross-chain statement. https://web.archive.org/web/20190819040548/https://support.lavu.com/hc/en-us/articles/213223037-NEW-Lavu-Gift-Card-Overview-Adding-Cards-as-Menu-Items · retrieved 2026-09-13 adversarially verified

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

From Lavu's archived Zendesk help centre, 'Setting up Lavu Loyalty' (article dated 12 May 2018; Wayback capture 20 July 2019). Its Loyalty Program Features list says 'Customers can be issued a loyalty card, or use their telephone number as their member number' and 'Loyalty cards and numbers can be used across chain locations.' That establishes that one loyalty identifier works across a Configure Chains group; it implies, but does not explicitly state, that the points balance follows the card between locations. It is partial because the claim also requires a single customer profile with stored order history shared chain-wide: loyalty is keyed to a card or number, and no archived or current article says customer records or order history are shared across chained locations. This is the 2018-2019 archived state; the current help centre's loyalty articles are also card-based and neither repeat nor contradict the cross-chain statement. https://web.archive.org/web/20190720075830/https://support.lavu.com/hc/en-us/articles/229623027-Setting-up-Lavu-Loyalty · retrieved 2026-09-13 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

CLAIM: 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. VERDICT: no. THE GAP THE 324th NAMED IS NOW CLOSED: that pass held this cell because "the legacy control panel's revenue-centre settings are not in this corpus". They are now. Revenue Centres are documented and they are AREAS, not brands: "Revenue Centers are used to track revenue within a specified area within a location (i.e. Bar, Dining Room, etc.). Once the Revenue Centers have been created in Settings they will need to be applied to the tables in the Layout. A location can also assign default Revenue Centers based on Service Types" — with exactly three assignment slots, "Default Revenue Center for Tables", "Revenue Center for Quick Serves", "Revenue Center for Tabs" (https://support.lavu.com/hc/en-us/articles/200573805-Section-4-6-Revenue-Centers, retired KB via Wayback, corroboration; 'revenue center(s)' also scores 19 substring / 16 tokenised in the CURRENT censused KB). So the one conjunct that is met is separately reportable revenue by AREA, and it is met by a feature whose unit is a table or a service type — not a brand, not a menu, not a receipt identity. The multi-unit unit of account everywhere else in Lavu is the "dataname" (one location) inside a chain: chain tooling is menu DISTRIBUTION ("Select location(s) within your company's chain where you would like to send Menu information"; "Menu transfer is not available when the dataname is not part of a chain") and chain currency. CONTROLS: "virtual brand" 0, "multi-brand" 0, "multiple brands" 0, "second brand" 0, "ghost kitchen" 0, "separate receipt" 0 tokenised over the 249-article KB and over the 1,817-file CP3 corpus; 'concept' 2 tokenised in the KB, both marketing prose. POISON on the marketing site: over the lavu.com WordPress census "virtual brand" scores 2 tokenised and BOTH are the title of one blog post listed in a sidebar ("AI for Restaurant Ghost Kitchens: Optimize Virtual Brand Operations"), not a capability. BOUND — THE CENSUS THIS PASS BUILT (new: nobody had validated the Lavu KB as a census before). support.lavu.com is a HUBSPOT knowledge base, not Zendesk. Two independent publisher listings agree: (a) the sitemap names 249 /en/knowledge/ articles; (b) the HubSpot search API, never used on this host before — https://support.lavu.com/_hcms/search?term=<t>&type=KNOWLEDGE_ARTICLE&limit=50&offset=<n>, swept over 120 terms (script hs-sweep.mjs) — returns 241 unique articles and every one of them is inside the 249, 0 extra. CITED-SLUG VALIDATION: of 78 distinct support.lavu.com URLs cited in Lavu's own claims.jsonl, 72 are in the 249; the 6 that are not are 3 category index pages (/lavu-pos, /menu-drive, /lavu-equipment-hardware) and 3 URLs on the RETIRED Zendesk KB (/hc/en-us/articles/...), which now 404 (support.lavu.com/hc/en-us 301s to /en/knowledge). Corpus = 3,170,001 chars of article text. (c) HREF FIXPOINT run this pass over all 249 raw bodies re-fetched today (34.8 MB, script raw.mjs): 251 distinct /en/knowledge/ URLs are referenced from inside the bodies and exactly 7 are absent from the sitemap — and all 7 are CATEGORY index pages (lavu-pos, lavu-payroll, lavu-control-panel, lavu-equipment-hardware, lavu-pay, onboarding, menu-drive), ZERO orphan articles. The 249 is therefore a census of this publisher, not a floor. Second census: the Control Panel 3 SPA source-map corpus (prod-cp3-01.aws2.poslavu.com, 99 of 100 chunks, 1,817 first-party files, 4,127,475 chars). Third: the lavu.com WordPress site census (2,567,819 chars). RETIRED SURFACE RECOVERED THIS PASS, CORROBORATION ONLY (merge policy bars a no resting on retired docs): the pre-HubSpot Zendesk KB is indexed by Wayback CDX at 514 distinct /hc/en-us/articles/ URLs (cdx-hc.json); 17 fetched via /web/<ts>id_/. Retrieved 2026-09-18. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-09-18 adversarially verified

Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.

multi-location-multi-tax-jurisdiction

Explicitly designed for it: "If you have multiple business locations in different regions or states with varying tax structures, Tax Configuration will allow you to maintain those differences while also syncing your menu over time. It also allows you to keep taxes from changing with each sync." Underneath, each location builds tax profiles under Payments > Tax Profiles carrying one or more named rates (entered as decimals, e.g. 0.085 for 8.5%) attached to menu categories and items, with an option to include tax in displayed prices. Lavu is explicit that it "cannot tell you or assist in determining what you should be charging for taxes" — rate determination is the operator's. https://support.lavu.com/en/knowledge/multi-location-menu-management · retrieved 2026-08-02

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

Per-location labor rules are configurable and partly terminal-enforced: overtime/double-time thresholds (hours per day, days per week, hours per week, or combinations), paid-break settings, and clock restrictions ('Prevent servers from clocking out when they have open orders', early/late clock-in blocks). Shortfalls: no location-group central management - MLMM syncs menus, taxes, discounts, payment types, and happy hours, not workforce settings - and no predictive-scheduling compliance features. https://support.lavu.com/en/knowledge/workforce-settings · retrieved 2026-08-05

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

Retrieved on verification: "Lavu POS" is published free on the App Store by "Lavu Inc" with stated compatibility "Requires iPadOS 13.0 or later" (iOS 13.0+ on iPhone, macOS 11.0+ on Apple silicon). Any operator-purchased iPad meeting that floor runs the client; there is no vendor-imaged or proprietary terminal gate. Scope caveat: commodity within the Apple ecosystem only — Lavu publishes no Android or Windows POS client. https://apps.apple.com/us/app/lavu-pos/id1449885676 · 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

iPad / iOS is named as the client platform; minimum iPadOS version and device specs are not published on the public site. https://lavu.com/restaurant-pos/ · retrieved 2026-08-01

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

hardware-handheld-purpose-built

Positive enumeration, twice over. The KB's Equipment and Hardware category lists every supported device by group, and its entire Card Readers group is separate readers driven from a tablet: IDTech VP3300, LANE 3000, Adyen NYC1, BOLT EMV, Verifone, PAX. Lavu's own store (46 priced SKUs) sells its handheld as a bundle, not a device: the Wi-Fi Handheld Bundle is "1 x Apple iPad mini (A17 Pro) ... 1 x VAULT GoWork Pro case ... 1 x Adyen NYC1 Card Reader". No integrated-reader handheld appears in either list, and no drop rating or IP ingress rating is published for anything - the case is described only as "rugged" with "drop protection". https://support.lavu.com/en/knowledge/lavu-equipment-hardware · retrieved 2026-08-09 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

Lavu's order-taking hardware is standard Apple iOS devices - the product is an iPad POS and the settings expose order pads for 'iPad' and 'iPhone/iPod' - with sealed, non-swappable batteries; Lavu publishes no rated shift battery life anywhere on lavu.com or in the help centre, and no vendor battery-swap program exists. https://support.lavu.com/en/knowledge/advanced-location-settings-order-options · 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

A vendor-sold failover modem provides 'a 5G LTE connection to the internet for your restaurant', is 'compatible with the networking equipment that we sell', activates automatically on ISP outage and reroutes iPad traffic transparently with 'no acknowledgments nor limitations on your software'. Shortfalls: it is a store-network WAN failover, not handheld-level cellular - nothing documents LTE in the handheld devices themselves or a fallback that survives loss of the local Wi-Fi network (as opposed to the ISP). https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · 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

Orders, kitchen sends and cash sales continue offline per Crash Kit 101. Shortfall: the claim requires the vendor to document explicitly which functions degrade. Only card and gift-card validation is named as internet-dependent; loyalty lookup and refunds are addressed nowhere, and the marketing offline page contradicts the support article by claiming payments work locally. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-02 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 KDS with documented station routing: create a printer profile with the kitchen label per screen, then "assign your menu categories to your new KDS printer profile. That way when your employees click Send on an order, the order will be sent to your Lavu KDS screen." Touch input and order timers are documented in the KDS settings article, and Lavu sells Epson KDS station bundles under its own brand, so this is first-party rather than integration-only. Course/fire timing beyond elapsed-time timers remains thin. https://support.lavu.com/en/knowledge/lavu-kds-printer-profile · 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

Kiosk is a documented first-party product (three help-centre articles, monitored status component). Shortfall: the claim requires both countertop and freestanding form factors and documented ADA compliance; Lavu publishes neither a kiosk form-factor list nor any accessibility conformance statement. https://support.lavu.com/en/knowledge/lavu-pos · retrieved 2026-08-02 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

Positive absence across two independent first-party enumerations of the same proposition. The help centre's Equipment & Hardware category declares its own complete subsection list - Networking, Printers & Cash Drawers, Card Readers, Other, Epson KDS - and every article beneath it is a printer, cash drawer, router, access point, card reader or KDS screen. Lavu's own store is separately enumerable through its Shopify collection JSON and holds forty products across twelve collections (card readers, terminals, KDS, cash drawer, networking, printers, stands, iPad, gift cards, discounted, plus paper and accessories); neither list contains an outdoor menu board, an order confirmation display, a speaker post or a headset system, and no timer or speed-of-service measurement is documented for a lane. https://support.lavu.com/en/knowledge/lavu-equipment-hardware · retrieved 2026-09-04 adversarially verified

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

Help-centre article 'Compatible Star Micronics Printers', subtitled 'Model of Star Printers that Lavu supports': "Lavu is compatible with 2 series of Star Micronics printers. The TSP 650 series (currently the TSP 654) [and] The SP700 series (currently the SP742) ... The TSP 650 printers are thermal printers, and are best used as receipt printers in your front of house. Meanwhile, the SP 700 printers are impact printers, and work great in the kitchen." A second manufacturer is documented at equal depth under Lavu Equipment & Hardware > Printers & Cash Drawers: Installation - Epson TM-T88VII Printer, Setting a Static IP Address to the Epson TM-m30iii Thermal Receipt Printer, Set a Static IP address for your Epson Printer, Epson Wireless Printer Setup (and the TM Utility variant), Basic Printer Setup, Printer Redirects and Epson Printer Error Light Codes. The static-IP articles are the LAN/Ethernet path, and Printer Redirects plus Assigning Printers To Modifiers document kitchen routing. Both are standard third-party ESC/POS thermal and impact units, not vendor-locked hardware. Retrieved from the 250-article support.lavu.com dump, 2026-08-08. https://support.lavu.com/en/knowledge/compatible-star-micronics-printers · retrieved 2026-08-08

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

Every element of the peripheral set is documented in the help centre. Multi-drawer per terminal: 'Dual Cash Drawer Setup' - "with a dual cash drawer setup, you can connect a single receipt printer/POS to two cash drawers ... the additional piece of hardware you will need is Lavu's Dual Cash Drawer Splitter ... allows Lavu to open specific cash drawers based on the employee that is logged in", with the matching Advanced Location Settings > Checkout Options and per-printer-profile toggles; plus 'APG Cash Drawer: Setup and Usage Guide'. Scales: 'Using the Tor Rey L-EQ Bluetooth Scale' - "Lavu sells a Bluetooth connect scale to assist customers in determining prices for weighed menu items", configured from Advanced Location Settings. Customer display: 'Lavu Customer Facing Display' - "displays items, taxes, and check totals to the restaurant patron and can capture signatures for credit card transactions ... an additional iPad connected to your network with the Lavu Display App installed." Barcode scanning: "The Lavu POS is able to use the iPad's built in camera to scan bar codes" to ring items up, take Lavu Gift payment and read loyalty numbers (Lavu's Camera Scanner). SHORTFALLS: (1) no published compatibility list except for printers - 'Compatible Star Micronics Printers' is the only supported-models article in the corpus; drawers, scales and displays are documented as single named units (APG, Tor Rey L-EQ, Lavu Display App on iPad) with no statement of what else works; (2) barcode input is documented via the iPad camera only, with no supported USB/Bluetooth scanner list; (3) lavu.com/hardware/ redirects to the homepage, so no first-party catalogue exists. Retrieved 2026-08-08. https://support.lavu.com/en/knowledge/lavu-equipment-hardware · retrieved 2026-08-08

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

Encrypting card entry is documented and hardware-based - "the basics of PCI compliance include using properly encrypted card readers", and "the card readers you purchase through Lavu, as well as the Lavu POS software, are all PCI compliant" - on PTS-listed devices (IDTech VP3300, Ingenico LANE 3000, Adyen NYC1). The shortfall is explicit rather than merely undocumented: Lavu's own guide to the CardPointe PCI form instructs merchants to answer "Q: Your Point-to-point Encryption system? A: No", and walks them through a full guided assessment (payment application, remote access, information security policy). No validated P2PE listing is cited and no resulting SAQ type is ever named. https://support.lavu.com/en/knowledge/cardpointe-pci-compliance · retrieved 2026-08-09 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

Lavu's product page 'Tap to Pay on iPhone' (lavu.com/tap-to-pay-on-iphone/, datePublished 2026-09-09T20:56:48+00:00, retrieved 2026-09-13) states acceptance on a commodity iPhone with no separate reader: 'Nothing to buy, nothing to charge, nothing to replace when it walks off. The iPhone in your server's apron becomes the card reader'; FAQ: 'iPhone XS or later. There is no dongle, sled, or separate reader to add - the phone is the terminal.' In-app flow: 'Choose Tap to Pay on iPhone from the payment options at checkout'. Not a catch-all (7,236 stripped chars against the 43,934-char soft-404 body, 2026-09-13). PARTIAL, shortfalls: (1) marketing page only (grade C), published four days before retrieval, with no support.lavu.com article and no Tap to Pay note in the App Store Lavu POS v6.3 (Aug 4 2026) listing, so there is no product documentation of setup or availability; (2) phone only and iPhone only - no Tap to Pay on Android statement ('Android' 0 occurrences) and no tablet acceptance, although the claim covers 'phone or tablet' and Lavu's terminal is the iPad. Re-check after 2026-09-13 for documentation. https://lavu.com/tap-to-pay-on-iphone/ · retrieved 2026-09-13 adversarially verified

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

hardware-pricing-transparency

Lavu publishes 46 hardware SKUs with public prices, no login and no quote request: Adyen NYC1 Card Reader $119 (SKU ADYEN-NYC1), NYC1 Dock $125, APG Cash Drawer 16in $120, Epson receipt printer $275, Epson TM-L90II label printer $440, Epson TrueOrder KDS $1,128, iPad mini (A17 Pro) Wi-Fi $499 / Wi-Fi+Cellular $749, iPad Air 13in $799, VAULT GoWork Pro case $240, Wi-Fi Handheld Bundle $1,270 (BUNDLE-MOBILE-IPADMINI), Cellular Handheld $1,350, Complete POS Station Bundle iPad Air 13in $2,374, networking bundles $1,800 / $3,348 / $4,140. The same catalogue is served as JSON from buy.lavu.com/api/hardware with per-SKU price, category and finance fields. https://shop.lavu.com/ · retrieved 2026-08-09 adversarially verified

Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator

hardware-ownership-vs-lease

The Terms of Service state both models explicitly: 'Lavu Products may be purchased or leased as indicated in your order'; 'Title for Lavu Products purchased from us passes to the purchaser at the time of delivery by Lavu to the freight carrier', while leased or financed products 'shall at all times remain the property of Lavu or our Financing Partner' and must be returned when the lease expires. https://lavu.com/terms-of-service/ · 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

Lavu's own comparison page states 'It is flexible and not hardware locked. You are not forced into proprietary hardware. You can buy replacements anywhere.' The terminal is a customer-owned iPad running App Store apps (Lavu POS, apps.apple.com/us/app/lavu-pos/id1449885676), and shop.lavu.com sells commodity Epson, Star, APG and Apple hardware that the vendor has no means to brick. Shortfall: the statement is marketing and does not address post-cancellation specifically; the card readers Lavu sells (Adyen NYC1, IDTech VP3300, Ingenico LANE 3000) are documented only as paired to Lavu Pay / CardConnect gateways and their re-use with another processor is not addressed anywhere. https://lavu.com/restaurant-pos/multi-location/ · retrieved 2026-09-02 adversarially verified

Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator

hardware-rma-sla

A replacement SLA is published: LavuCare ('included by default on all Lavu deals for $199 per year') offers 'overnight hardware replacement in the event of equipment defect or failure', and the subscribable NDR Service processes weekday replacement orders received before 5PM ET for same-business-day shipment and next-business-day delivery. Shortfall: no hardware warranty term is published - the ToS references an 'original warranty period' without stating its length. https://lavu.com/terms-of-service/ · retrieved 2026-08-05

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

hardware-byod

The POS app installs from the public App Store onto customer-supplied iOS hardware ('the availability of the Lavu Products is dependent on the App Store from which you received the license'; you must provide 'compatible mobile devices'), and the settings expose iPhone/iPod order pads alongside iPads. Shortfalls: no documented BYOD program or permission/security model for staff personal phones - the only device-security requirement stated is that illegally altered (jailbroken) devices are prohibited. https://lavu.com/terms-of-service/ · 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

Positive evidence of the opposite operating model. Lavu documents version handling as a manual per-device chore performed by the operator on each iPad - 'Tap the menu button ... Tap Settings ... Tap About Lavu POS. The app version will be listed at the top' and 'To get the latest version of the app, simply search for Lavu in the Apple App Store, and tap the Update button' - with the consistency burden also on the operator ('if you are using multiple iPads, that they all have the same version of Lavu installed'). That forecloses both fleet version visibility and staged rollout. Device health is likewise per-device and physical: Basic Network Troubleshooting diagnoses terminals, printers and readers by reading router port lights and access-point LEDs rather than a console. The only remote-access capability Lavu documents belongs to Lavu rather than the merchant - the Terms and Conditions reserve tooling 'to allow remote access to the devices or computers' for Lavu's own technical support. https://support.lavu.com/en/knowledge/lavu-app-version · retrieved 2026-09-04 adversarially verified

Integrates with specialty beverage hardware — self-pour tap walls, flow meters, or liquor pour spouts — such that pours post to a POS tab automatically.

hardware-selfpour-scales

Named partners exist and nothing beyond the name does. Lavu's own integrations catalogue lists Digital Pour (self-pour and draft-beverage monitoring) and Bar-i (weight-based liquid accounting) as supported integrations, which is more than an absence. Shortfall: the integration is asserted only as a catalogue tile at grade C - the complete 249-article help centre carries no setup or configuration article for either partner, nothing documents that a pour posts automatically to an open POS tab rather than feeding a back-office variance report, and Lavu's own forty-SKU store sells no flow meter, pour spout or tap-wall hardware. The one beverage-adjacent device Lavu documents is a Tor Rey L-EQ Bluetooth scale for pricing weighed items at the POS. https://lavu.com/integrations/ · retrieved 2026-09-04 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

326th: MOVED unknown -> no. The 325th held this because a data-table enumeration is not a hardware-compatibility list; the missing piece is now in hand - Lavu's OWN INTEGRATION ENUMERATION, rebuilt this month: lavu.com/integrations/ lists 23 named partners in five categories (Inventory: Bar-i, Digital Pour, Marketman, CheddarSuite; Payments & Ordering: Up'n Go, CheckPlease; Loyalty: OpenTable, LoyaltyMatch, Pepper; Accounting & Payroll: Restaurant365, Shogo, Dolce, QuickBooks, Xero, Davo; Online Ordering & Delivery: Otter, Chowly, DoorDash, Grubhub, Uber Eats, Flipdish, Checkmate, Open Dining) and NOT ONE is telephony; the same page's product index (Front of House / Back Office / Digital Ordering & Delivery, including Pilot, Pizza Creator, Delivery, Routing, Customer Facing Display, Digital Menu Boards) contains no phone or caller-ID component. CONTROLS over 11.5 MB (245-article KB dump re-verified complete against today's 249-entry sitemap; lavu.com WP census 344 items / 2,567,819 chars; CP3 source maps; the Lavu To Go ordering app source map; api_doc.html; api.lavu.com swagger): 'caller id' 0, telephony 0, DNIS 0, PBX 0, 'phone system' 0. POISON PUBLISHED, THREE TRAPS: 'caller' scores 42 on a substring grep and exactly 1 tokenised, and that one is a JAVASCRIPT COMMENT in Lavu's own shipped code ('unless the caller passes hideToast: true') - a function caller, not a telephone one, so every substring hit on this vendor is 'installer/smaller/miscellaneous'-class noise; 'ANI' scores 485 substring and 0 tokenised; 'SIP' scores 158 substring and 0 tokenised. Retrieved 2026-09-18. https://lavu.com/integrations/ · retrieved 2026-09-18 adversarially verified

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

extensibility-public-api-docs

Re-probed 2026-08-06 with unauthenticated curl: /docs/swagger.json returns the complete Swagger 2.0 spec (72KB, 26 paths, 40 definitions, securityDefinitions), /docs/swagger.yaml returns the same 84KB in YAML, and /docs/swagger/ and /docs/redoc/ both render. No signed agreement, NDA or sales call intervenes. The earlier 'requires login' reading confused endpoint auth with doc access: the spec's own text says 'LavuAPI is completely protected and requires authentication to access any of the endpoints', and /api/v1/customer/menus/ does return 401, but the reference itself is open. Caveats short of a shortfall: the spec self-describes as 'under completion' and one link still points at http://127.0.0.1:8000/docs/swagger.yaml. https://api.lavu.com/docs/swagger.json · retrieved 2026-08-06

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

extensibility-api-access-cost

No API line appears anywhere in Lavu's published price list: the plan catalogue (Starter $0, Growth $79, Enterprise quote-only) and the nine-module add-on catalogue at buy.lavu.com/api/addons price everything Lavu sells a la carte and contain no API, integration or data-access fee; the Terms of Service fee clauses never mention the API; and 'Open API for integrations' is marketed as a standard feature on lavu.com/restaurant-pos/multi-location. Shortfall: access is partner-gated with issued credentials, and no source says in words that API access is included at the base tier, so a fee or plan requirement applied inside the credential process cannot be excluded. https://buy.lavu.com/api/plans · retrieved 2026-09-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

The API portal's own documentation states 'LavuAPI is completely protected and requires authentication to access any of the endpoints, including the documentation', with OAuth authorization granted by an existing customer account ('the user should authorize the OAuth application explicitly'). No sandbox, test environment, seeded data, or open developer signup exists anywhere in the API documentation. https://api.lavu.com/docs/swagger.json · retrieved 2026-08-05

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

The publicly retrievable OpenAPI spec at api.lavu.com documents an OAuth 2 flow for third-party apps: "To work with LavuAPI.Customer, the user should authorize the OAuth application explicitly", with /oauth/authorize/, /oauth/token/ and /oauth/revoke-token/ endpoints and per-endpoint scopes — "Each endpoint has a unique scope to access and consume it" (e.g. customer_profile on the profile endpoint). Operator-granted, scoped and revocable are all present. Caveat: the spec's formal securityDefinitions also declare HTTP Basic, and the info text lists session login as an alternative scheme, so OAuth is available rather than enforced. https://api.lavu.com/docs/swagger.json · retrieved 2026-08-03

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

extensibility-webhooks-push

The complete published OpenAPI spec for api.lavu.com enumerates 26 endpoint paths — token, profile, location, menus, orders, checks, payments, payment intents — and contains no webhook, event-subscription, callback or notification endpoint in any path or description; order lifecycle data is exposed only through pollable GET /v1/customer/orders/ and /v2/customer/orders/ resources. No support-centre article mentions webhooks either. The vendor's enumerated integration surface is pull-only, which is positive evidence that push webhooks are not offered. https://api.lavu.com/docs/swagger.json · retrieved 2026-08-03

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

No webhooks exist in either published API surface: the OpenAPI spec's 26 paths are all request/response (reads plus order/payment creation), and the legacy admin.poslavu.com API is a poll-only table query interface. Nothing documents event delivery, signing, retries, or a replayable event log, so the claim's documented-reliability requirements cannot be met. https://api.lavu.com/docs/swagger.json · retrieved 2026-08-05

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

Order injection is documented in both API generations. The published OpenAPI spec exposes POST /v2/customer/create-order/, whose LavuApiOrderSerializer body requires customer, items[] (item_id, quantity), location_id, tablename/tabname and order_status and optionally carries subtotal, tax, total, server and special_instructions, with POST /v2/customer/close-order/, POST /v2/create-payment-record/ and external-payment/payment-intent routes completing the lifecycle. The legacy doc at admin.poslavu.com/cp/areas/api_doc.html demonstrates the same thing on the old stack: 'cmd=insert&table=orders', then 'cmd=insert&table=order_contents' (item name, price, quantity, modifiers), then 'cmd=insert&table=order_payments', authenticated by dataname/key/token and returning '<result><id>id of the new entry</id><order_id>the order id</order_id></result>'. Caveat, scored elsewhere: access is gated to an authorized customer account and there is no open sandbox or developer signup. https://api.lavu.com/docs/swagger.json · retrieved 2026-08-06

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

extensibility-menu-write-api

Both published API surfaces were read, and the audit changed what this note says. The modern contract is read-only for menus: the Swagger 2.0 spec (72,254 bytes, retrieved unauthenticated) declares 26 paths of which the menu resources are GET /api/v1/customer/menus/ and GET /api/v1/customer/menus/{id}/, and every write path is accounted for elsewhere (three token routes, create-order, close-order, create-payment-record, external-payment, payment-intent). The legacy POSLavu API at admin.poslavu.com/cp/areas/api_doc.html is NOT read-only as an earlier reading had it - its worked PHP example posts 'cmd=insert&table=orders', 'cmd=insert&table=order_contents' and 'cmd=insert&table=order_payments', a generic insert verb that the document's own Post Variables list never declares. Its Available Tables list does include menu_groups, menu_categories and menu_items, so an undocumented menu insert cannot be excluded. What can be excluded is the claim as written: no update or delete verb is documented on either surface, and neither surface exposes a modifier resource at all - the legacy table list has none, and the modern MenuSerializer returns modifications as read-only output. Menu maintenance is documented instead as UI or sync work: Multi-Location Menu Management pushes from a primary location, and MenuDrive's Sync Menu exports entities outward to DoorDash. https://api.lavu.com/docs/swagger.json · retrieved 2026-09-04 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 features-completed count against the eight high-quality features the program requires. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is the instrument the program page points to when it says the roster is tracked in real time, and it supersedes the 2026 announcement post most of this corpus cited — that post introduces its ten names with the word `include`, which makes it a floor, not a ceiling. In that registry this vendor is the entry `lavu_production`, rendered as 'Lavu', with qualityStatus CERTIFIED and 2 of the 8 high-quality features built. CERTIFIED and AT_RISK are the program's other two tiers, so this is positive evidence of non-membership rather than a failure to find the vendor: it is present in the registry and carries a status that is not PREFERRED. 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

Same correction — the integrations page's "Integration available with integrator" annotation on Uber Eats and Grubhub is affirmative evidence against first-party status for those two; DoorDash alone is documented direct. https://lavu.com/integrations/ · retrieved 2026-08-01 adversarially verified

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

extensibility-middleware-compatibility

Three major aggregation platforms are named as supported endpoints on Lavu's own integrations page: Otter, Chowly and Checkmate. https://lavu.com/integrations/ · 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

Xero — one of the two headline connectors — is annotated "Integration available with integrator" on Lavu's own integrations page, i.e. not a first-party connector. QuickBooks, Shogo, Restaurant365 and Davo are listed without that caveat. Journal-entry/GL mapping depth remains undocumented. https://lavu.com/integrations/ · retrieved 2026-08-01 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

Lavu sells its own payroll and integrates QuickBooks and Restaurant365 workforce; two named third-party payroll providers (Gusto, ADP, Paychex, Paylocity) are not listed. https://lavu.com/integrations/ · retrieved 2026-08-01

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

extensibility-app-marketplace

A public integrations catalog lists named third-party apps by category, and 'Lavu Store' is a monitored status-page component; operator self-install is not documented. https://lavu.com/integrations/ · retrieved 2026-08-01

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 API can drive transactions: documented POST endpoints /v2/customer/create-order/ (a full order payload including items, modifiers, seats/courses, checks, custom charges, and delivery address), /v2/customer/close-order/, /v2/create-payment-record/, and external-payment/payment-intent routes. Shortfalls: no vendor-documented headless or embedded-ordering program surrounds them, access is gated to authorized customer accounts, and the docs self-describe as 'under completion'. https://api.lavu.com/docs/swagger.json · 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

Verified verbatim: "Lavu has no obligation to retain, provide access to, or allow extraction of User Content or User Data post-termination, except as required by applicable law or card association rules. Lavu may delete all User Content and User Data immediately upon termination, without liability to you or any third party." An express disclaimer of the extraction obligation is positive evidence of absence. https://lavu.com/terms-of-service/ · retrieved 2026-08-02 adversarially verified

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

reliability-offline-order-entry

Crash Kit 101 lists, for operation without internet, "Add food and drink to open orders", "Start new orders", "Send orders to the kitchen" and "Print checks" — order entry, ticket routing and check printing, which is the claim exactly. Re-evidenced from a marketing page to vendor documentation on verification. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-02 adversarially verified

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

reliability-offline-card-auth

The vendor sentence is "Lavu caches card transactions locally during an outage and processes them when connectivity is restored. Standard risk thresholds apply." That is store-and-forward CAPTURE, not offline AUTHORIZATION — nothing is authorized while offline, and Lavu never claims it is. Source is a marketing page with a comparison table, not documentation. This is exactly the cell the brief says to hold to the highest bar; the dossier already scores payments-offline-store-and-forward as partial, so scoring the same mechanism "yes" here is double-counting marketing copy. https://lavu.com/restaurant-pos/offline-mode · retrieved 2026-08-01 adversarially verified

The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator

reliability-offline-decline-liability

Positive absence in the place the disclosure would live. Crash Kit 101 is Lavu’s own outage guidance and characterises store-and-forward only as trading verification speed for operational continuity — no allocation of loss on a post-reconnect decline, no per-transaction cap, no cumulative cap, no reconnect failure report. The marketing offline page says only "Standard risk thresholds apply." https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-02 adversarially verified

Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator

reliability-lan-degraded-multi-terminal

From Lavu's archived Zendesk help centre, 'Offline Order Sync (P2P Mode)' (article dated 8 August 2019; Wayback capture 20 August 2019), not the current support.lavu.com. It says 'order updates are shared across devices through the network by default. That way if the connection is ever lost, syncing remains in tact as if you were still online', replacing the earlier behaviour where updates 'would be stored locally on the iPad', so order state is shared across iPads rather than kept as per-terminal islands. It is partial because of limits the article names itself: a Lavu Admin must enable it, it requires Lavu 4.1.0+, 'only 8 iPads' could connect at once, and while offline the Server Tips page, Pizza Creator, FOH reports, clocking in and out, 86 countdowns, Inventory, Manager Functions and Lavu Gift/Loyalty are unavailable. Lavu's 'Release Note Highlights 2019' (17 October 2019) later lists 'Offline support for 50+ devices' and 'Offline support for the pizza creator'. This is the documented state in 2019; the current 250-article help centre never mentions P2P or Offline Order Sync, so it neither confirms that the mode still ships nor contradicts it. https://web.archive.org/web/20190820211445/https://support.lavu.com/hc/en-us/articles/360026467394-Offline-Order-Sync-P2P-Mode- · retrieved 2026-09-13 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

An on-premise component exists: "Lavu Local Server" is one of 14 independently monitored components on the public status page, alongside Point of Sale, KDS, Kiosk, Loyalty, Menu Drive, API, Lavu To Go, Order Status Monitor, Pilot, Lavu Store, Phone System, Payment Processing and Admin Control Panel. Shortfall: Lavu publishes no architecture, install or configuration documentation for it — the legacy article stating it is a prerequisite for KDS Pro (support.lavu.com/hc/en-us/articles/200108983) returns HTTP 404 to retrieval, and the current outage article never mentions a local server at all. Its role on the ordering path is asserted nowhere. https://status.lavu.com/ · retrieved 2026-08-02 adversarially verified

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

reliability-offline-kds-printing

Crash Kit 101 lists "Send orders to the kitchen" and "Print checks" among the functions that continue during an outage. The claim is satisfied by kitchen printer routing alone ("kitchen display and/or kitchen printer routing"). Re-evidenced from a marketing page to vendor documentation on verification. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-02 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

Lavu's documented mechanism for an unavailable kitchen printer is a manual workaround, not failover: Printer Redirects "are a way you can temporarily change which kitchen printers your menu items print from", enabled by hand on the POS, and "when you are finished using that redirect, you will need to come back to this screen to disable your redirect". Basic Printer Setup's enumerated per-printer settings (setting, name, static IP, port, type, command set, model, image capability) contain no backup-printer or failover option, and the Epson troubleshooting article shows an unreachable printer surfaces a "Failed to Write" error rather than re-routing. A documented manual redirect plus a settings enumeration with no backup option is positive evidence there is no automatic failover with staff alerting. https://support.lavu.com/en/knowledge/printer-redirects · 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

CLAIM: the vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (last-write-wins, merge, or operator prompt). VERDICT: no. Lavu documents the sync MECHANISM in detail and never states a resolution RULE. The mechanism documents are: "Offline Order Sync (P2P Mode)" — "This isn't an 'Offline Mode' for the entire POS, more of an 'Always Syncing' mode ... order updates are shared across devices through the network by default. That way if the connection is ever lost, syncing remains in tact as if you were still online" — plus a Peer Dashboard that only reports reachability ("A green light indicates an active connection, while a red light will indicate an inactive connection"); "Section 7.3: Sync Status (Lavu Local Server Only)" — which shows only "how much time has passed since your Lavu Local Server last synced with the cloud" and whose whole troubleshooting list is connectivity checks; and "Lavu 3: My Orders are not syncing between iPads" — whose entire answer is a polling interval, "Seconds between Dining Room view auto refresh ... should be set to 20 to 40 seconds". Not one of them says what happens when the same order is edited on two partitioned devices. (Retired-KB items are corroboration only.) CONTROLS: over the 249-article current KB 'conflict' scores exactly 1 tokenised and it is not about devices — it is QR-code store settings that "may conflict with your already established online storefront"; "last-write" 0, "last write wins" 0, "which version" 0, "sync conflict" 0. Over the 1,817-file CP3 source corpus 'conflict' scores 19 on a substring grep and 1 tokenised. POISON PUBLISHED, and it is the trap on this cell: the three words a re-tester would reach for all score non-zero and NONE is about synchronisation — 'merge' 11 tokenised, every one the POS's Merge Order / Add to Tab feature ("Select the Identifier to use when selecting order for Merge Order/Add to Tab"); 'reconcile' 2, both end-of-shift Server Summary reconciliation; 'overwrite' 1, and it is modifier inheritance ("a modifier attached to the item will overwrite any modifier attached to the category"). BOUND — THE CENSUS THIS PASS BUILT (new: nobody had validated the Lavu KB as a census before). support.lavu.com is a HUBSPOT knowledge base, not Zendesk. Two independent publisher listings agree: (a) the sitemap names 249 /en/knowledge/ articles; (b) the HubSpot search API, never used on this host before — https://support.lavu.com/_hcms/search?term=<t>&type=KNOWLEDGE_ARTICLE&limit=50&offset=<n>, swept over 120 terms (script hs-sweep.mjs) — returns 241 unique articles and every one of them is inside the 249, 0 extra. CITED-SLUG VALIDATION: of 78 distinct support.lavu.com URLs cited in Lavu's own claims.jsonl, 72 are in the 249; the 6 that are not are 3 category index pages (/lavu-pos, /menu-drive, /lavu-equipment-hardware) and 3 URLs on the RETIRED Zendesk KB (/hc/en-us/articles/...), which now 404 (support.lavu.com/hc/en-us 301s to /en/knowledge). Corpus = 3,170,001 chars of article text. (c) HREF FIXPOINT run this pass over all 249 raw bodies re-fetched today (34.8 MB, script raw.mjs): 251 distinct /en/knowledge/ URLs are referenced from inside the bodies and exactly 7 are absent from the sitemap — and all 7 are CATEGORY index pages (lavu-pos, lavu-payroll, lavu-control-panel, lavu-equipment-hardware, lavu-pay, onboarding, menu-drive), ZERO orphan articles. The 249 is therefore a census of this publisher, not a floor. Second census: the Control Panel 3 SPA source-map corpus (prod-cp3-01.aws2.poslavu.com, 99 of 100 chunks, 1,817 first-party files, 4,127,475 chars). Third: the lavu.com WordPress site census (2,567,819 chars). RETIRED SURFACE RECOVERED THIS PASS, CORROBORATION ONLY (merge policy bars a no resting on retired docs): the pre-HubSpot Zendesk KB is indexed by Wayback CDX at 514 distinct /hc/en-us/articles/ URLs (cdx-hc.json); 17 fetched via /web/<ts>id_/. POISON PUBLISHED (all measured over the 249-article KB, 3,170,001 chars): 'DoorDash' scores 284 tokenised and it is SITE CHROME — it appears in 241 of the 246 article sections, because every page's footer carries a "DoorDash Restaurant Solutions" link; anyone grepping DoorDash on this corpus will read 284 as a marketplace feature. 'master' scores 16 tokenised and ALL SIXTEEN are chain CURRENCY settings ("Set Master Currencies", "master currency list", "converted to a master currency"), never a master terminal. 'failover' scores 8 tokenised and ALL EIGHT are one article about an internet uplink device ("a failover modem ... connected to a wireless data provider (like Verizon, AT&T, or T-Mobile)"), never a POS role. 'driver' scores 2 on a substring grep and 0 tokenised. Retrieved 2026-09-18. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-09-18 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

Raised from "no" on verification. Crash Kit 101 does state offline behaviour affirmatively on both sides: it enumerates six functions that keep working and states that credit and gift card transactions specifically require active internet to validate card details, offering a CardPointe virtual terminal or iDynamo store-and-forward as workarounds. Shortfall: that is not the published matrix the claim describes — loyalty lookup, refunds and text-to-pay are never addressed, it lives in a troubleshooting article rather than a feature matrix, and it contradicts lavu.com/restaurant-pos/offline-mode. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · 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

status.lavu.com, no login, monitored components include Menu Drive, POS, Admin Control Panel, Kiosk, Loyalty, Lavu To Go, Order Status Monitor, Pilot, Lavu Local Server, Payment Processing, KDS, API, Lavu Store and Phone System, plus incident history and email/SMS/webhook/RSS subscriptions. No uptime percentages published. https://status.lavu.com/ · retrieved 2026-08-01

24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.

reliability-247-live-support

Pure marketing copy ("24/7 live support from real humans. No tickets. No runaround.") that the dossier's own dominant complaint theme directly contradicts, and that Lavu itself contradicts by requiring cancellations to go through a business-hours-style Customer Care line. Scoring it "yes" while simultaneously logging "Effectively there is no customer support" as the top complaint is internally inconsistent. https://lavu.com/service-promise/ · retrieved 2026-08-01 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

Lavu's purchase gateway (buy.lavu.com, linked from the lavu.com homepage) offers three implementation tiers: 'Self Setup' free ('Self-guided hardware install', 'Go-live check-in', knowledge base and email support); 'Guided Remote' $299 one-time ('Expert-led remote install', 'Remote staff training', 'Go-live support'), marked recommended; and 'Premium Onsite' $1,499 one-time, described as 'A Lavu technician comes to you to build, install, and train on-site' with features 'Onsite technician visit', 'In-person hardware & printer setup', 'In-person staff training', 'Launch-day support'. Shortfall: in-person install is a paid premium upgrade, not included in either the $0 Starter or $79/mo Growth plan, and it appears nowhere in the 250-article help centre, whose Onboarding hub calls the programme 'our self onboarding process' and whose only install article is the Pre-Remote Installation Checklist, which requires the merchant to drill counters, mount access points, unbox iPads and set up printers before a remote onboarding specialist begins. Graded C because the source is Lavu's commercial catalogue, not implementation documentation. https://buy.lavu.com/api/services · retrieved 2026-08-08

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

reliability-menu-build-service

MenuDrive advertises 'Done-for-you menu setup' for online ordering and Lavu claims a dedicated onboarding specialist; a first-party POS menu build as part of onboarding is not explicitly stated. https://lavu.com/online-ordering/ · retrieved 2026-08-01

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

reliability-hardware-replacement-sla

LavuCare is 'included by default on all Lavu deals for $199 per year, payable on the anniversary month of your contract' and provides 'overnight hardware replacement in the event of equipment defect or failure' (shipping and handling per replacement; excludes mass loss and natural disasters). The subscribable NDR Service additionally commits weekday orders before 5PM ET to same-business-day shipment for next-business-day delivery. https://lavu.com/terms-of-service/ · retrieved 2026-08-05

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

Lavu states only 'PCI compliant' on its payment-processing page. No AoC, no PCI DSS version, no P2PE listing reference and no trust center are published. https://lavu.com/payment-processing/ · retrieved 2026-08-01

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

reliability-mfa-role-based-access

Role-based permissions are documented: five access levels (0-4) gate POS and back-office functions from clock-in-only (0) through voids/discounts/refunds and reopening orders (2), full back-end menu/reports/inventory/management access (3), and multi-location switching (4), with per-function access-level dropdowns throughout Advanced Location Settings. Shortfall: no multi-factor authentication is documented for Control Panel or POS administrative logins anywhere - credentials are username/password (minimum 8 characters) and numeric PINs. https://support.lavu.com/en/knowledge/lavu-access-levels · retrieved 2026-08-05

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

reliability-self-serve-training

The library is public, free and login-free: a HubSpot help centre of roughly 250 articles with a dedicated Onboarding section (menu building, employee profiles, tax profiles, payroll, time cards) and some video content - Lavu Product Demonstration Videos ("Two demonstration videos showing off the Lavu POS, and Lavu Control Panel"), POS Video - Splitting Orders, POS - Tilling In and Out Video. Lavu's own $0 Self Setup service is described as "Knowledge base & step-by-step videos". Two shortfalls: the video content is a handful of clips, not a structured LMS, and nothing in the whole corpus documents a training or practice mode on the terminal. https://support.lavu.com/en/knowledge/lavu-product-demonstration-videos · retrieved 2026-08-09 adversarially verified

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

reliability-failover-terminal-role

CLAIM: any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. VERDICT: no — Lavu's documented architecture has no terminal server role to assume. The POS is cloud-primary; the only local server Lavu has ever shipped is a SINGLE dedicated appliance, not a terminal: "Lavu Local Server (LLS) is an on-site server designed to help locations continue running when a connection to the cloud server is down. LLS runs special Lavu software using an Apple Mac mini computer ... LLS acts as a 'middle-man' between your system and the cloud" (https://support.lavu.com/hc/en-us/articles/200074006, retired Zendesk KB via Wayback id_, corroboration only), and when it fails the documented remedy is manual: "Check that the LLS Mac mini is Turned ON. Check that the LLS Mac mini is hardwired (via ethernet cable) to your router" (Section 7.3: Sync Status). The successor design is a PEER MESH with no master at all — "order updates are shared across devices through the network by default ... Currently: only 8 iPads are able to be connected to each other at one time" (Offline Order Sync (P2P Mode)) — i.e. no device is designated primary, so nothing is promoted. The CURRENT, censused KB offers uplink redundancy instead of role redundancy: "a failover modem is a device that can be connected to a wireless data provider ... the iPads network traffic will automatically be routed through the failover modem" (Lavu Crash Kit 101). CONTROLS over the 249-article census and the 1,817-file CP3 source corpus: "master terminal" 0, "primary terminal" 0, "takes over" 0, "assume the role" 0, "elect" 0, "promote" 0, "backup server" 0, "peer-to-peer" 0 and P2P 0 in the current KB. BOUND — THE CENSUS THIS PASS BUILT (new: nobody had validated the Lavu KB as a census before). support.lavu.com is a HUBSPOT knowledge base, not Zendesk. Two independent publisher listings agree: (a) the sitemap names 249 /en/knowledge/ articles; (b) the HubSpot search API, never used on this host before — https://support.lavu.com/_hcms/search?term=<t>&type=KNOWLEDGE_ARTICLE&limit=50&offset=<n>, swept over 120 terms (script hs-sweep.mjs) — returns 241 unique articles and every one of them is inside the 249, 0 extra. CITED-SLUG VALIDATION: of 78 distinct support.lavu.com URLs cited in Lavu's own claims.jsonl, 72 are in the 249; the 6 that are not are 3 category index pages (/lavu-pos, /menu-drive, /lavu-equipment-hardware) and 3 URLs on the RETIRED Zendesk KB (/hc/en-us/articles/...), which now 404 (support.lavu.com/hc/en-us 301s to /en/knowledge). Corpus = 3,170,001 chars of article text. (c) HREF FIXPOINT run this pass over all 249 raw bodies re-fetched today (34.8 MB, script raw.mjs): 251 distinct /en/knowledge/ URLs are referenced from inside the bodies and exactly 7 are absent from the sitemap — and all 7 are CATEGORY index pages (lavu-pos, lavu-payroll, lavu-control-panel, lavu-equipment-hardware, lavu-pay, onboarding, menu-drive), ZERO orphan articles. The 249 is therefore a census of this publisher, not a floor. Second census: the Control Panel 3 SPA source-map corpus (prod-cp3-01.aws2.poslavu.com, 99 of 100 chunks, 1,817 first-party files, 4,127,475 chars). Third: the lavu.com WordPress site census (2,567,819 chars). RETIRED SURFACE RECOVERED THIS PASS, CORROBORATION ONLY (merge policy bars a no resting on retired docs): the pre-HubSpot Zendesk KB is indexed by Wayback CDX at 514 distinct /hc/en-us/articles/ URLs (cdx-hc.json); 17 fetched via /web/<ts>id_/. POISON PUBLISHED (all measured over the 249-article KB, 3,170,001 chars): 'DoorDash' scores 284 tokenised and it is SITE CHROME — it appears in 241 of the 246 article sections, because every page's footer carries a "DoorDash Restaurant Solutions" link; anyone grepping DoorDash on this corpus will read 284 as a marketplace feature. 'master' scores 16 tokenised and ALL SIXTEEN are chain CURRENCY settings ("Set Master Currencies", "master currency list", "converted to a master currency"), never a master terminal. 'failover' scores 8 tokenised and ALL EIGHT are one article about an internet uplink device ("a failover modem ... connected to a wireless data provider (like Verizon, AT&T, or T-Mobile)"), never a POS role. 'driver' scores 2 on a substring grep and 0 tokenised. Retrieved 2026-09-18. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-09-18 adversarially verified

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

reliability-cellular-backup

Vendor-documented and vendor-aligned hardware: 'a failover modem is a device that can be connected to a wireless data provider (like Verizon, AT&T, or T-Mobile) and provide a 5G LTE connection to the internet for your restaurant', sold as 'compatible with the networking equipment that we sell'; it 'will monitor the status of your internet connection, and will only activate once it has detected an outage', after which 'the iPads network traffic will automatically be routed through the failover modem' with 'no acknowledgments nor limitations on your software', including card and gift card transactions. https://support.lavu.com/en/knowledge/lavu-crash-kit-101 · retrieved 2026-08-05

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

ToS references a 'selected subscription term (e.g., monthly, annual)', so a monthly term appears to exist, but Lavu publishes no month-to-month offer or price. https://lavu.com/terms-of-service/ · 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

Verified verbatim in the ToS: "You may not cancel your subscription prior to the end of your then current subscription term", and "you will not be eligible for a prorated refund of any portion of the subscription fee paid for the then current subscription period." No dollar ETF is stated because early exit is forbidden outright — economically a term-remainder liability. https://lavu.com/terms-of-service/ · retrieved 2026-08-02 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

Auto-renewal for an equivalent period 'at our then current price' is published, and cancellation must precede the Renewal Commencement Date via a phone call to 505-559-5100 — but no notice window in days is stated. https://lavu.com/terms-of-service/ · retrieved 2026-08-01

The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator

commercial-processing-not-bundled

Third-party processing is documented, not forbidden. 'Is Lavu PCI Compliant?' addresses non-Lavu-Pay merchants directly: 'If you are not signed up for Lavu Pay, the card readers you will use are also PCI compliant. You should also reach out to your credit card processor to ensure that you remain PCI compliant through their standards and services.' End of Day - Tips & CC Batching is written processor-agnostically ('You can make changes to tips for most processors up until the point that you settle your batch'; 'We recommend setting up automatic batching with your credit card gateway'), and Advanced Location Settings - Checkout Options documents a non-integrated mode - 'Credit card info to ask for when integration is turned off' with options None / Card Type, Last Four, and Card Tip / Card Type and Card Tip - which lets any external terminal be used. Shortfall: Lavu publishes no list of supported integrated processors or gateways anywhere on support.lavu.com (250 articles) or lavu.com, so 'a processor of the operator's choice' is not established for integrated processing; the integrated path documented is Lavu Pay via CardConnect/CardPointe (plus Adyen NYC1 and Verifone readers), and Lavu itself calls the CC-integration-off setting 'uncommon'. Commercial terms for running off Lavu Pay are not published either - lavu.com has no pricing page (/pricing, /plans and /buy-now all 301 to the homepage). https://support.lavu.com/en/knowledge/advanced-location-settings-checkout-options · retrieved 2026-08-08

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

commercial-interchange-plus-published

No processing rate of any structure is published — the payment-processing page claims 'transparent pricing' while disclosing nothing. https://lavu.com/payment-processing/ · retrieved 2026-08-01

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

commercial-rate-increase-clause

Verified verbatim: the subscription "will automatically commence on the first day following the end of such period ... and continue for an additional equivalent period, at our then current price for such subscription." No cap on the increase, no stated notice period, and the cancellation clause forecloses a penalty-free exit in response. https://lavu.com/terms-of-service/ · retrieved 2026-08-02 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

Real published figures exist on Lavu's own ungated commerce host: three plans - Starter $0/month ("Core POS", "One terminal", 24/7 support), Growth $79/month ("Core POS", "Custom hardware options"), Enterprise quote-only (customPricing true) - plus per-module add-on prices (Kitchen Display $29, Payroll $39, Inventory $29, Reservations $19, Marketing $25, Loyalty $19, Gift Cards $15 per month) and onboarding services (Self Setup $0, Guided Remote $299 one-time). Read from buy.lavu.com/api/plans, /api/addons and /api/services. Shortfalls: no per-additional-terminal or per-additional-location increment is published anywhere - Starter simply includes "One terminal" - no card processing rate is published, and the Enterprise tier is contact-sales. lavu.com/pricing/ itself now 301s to the homepage. https://buy.lavu.com/ · retrieved 2026-08-09 adversarially verified

Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator

commercial-module-unbundling

Lavu's self-serve purchase gateway prices modules individually as monthly add-ons: Kitchen Display $29, Payroll $39, Reservations $19, Marketing $25, Inventory $29, Gift Cards $15, Loyalty $19, Customer Display $12, Employee Scheduling $22. Base plans are Starter $0/mo ('Core POS', one terminal, 24/7 support, 'Add-ons available'), Growth $79/mo ('Add-ons available'), and Enterprise at custom pricing, whose bundle list includes Digital General Manager, AI Reporting, AI Marketing, Inventory Management, Online Ordering, Loyalty Programs, Gift Cards and Advanced Analytics. Shortfalls: (1) the claim's cancellation half is unaddressed - no published terms state that an add-on can be dropped independently or that doing so leaves the base subscription priced as-is; lavu.com/terms-and-conditions is the only commercial document linked from the site and lavu.com has no pricing page at all (/pricing, /plans, /buy-now all 301 to the homepage); (2) online ordering (MenuDrive) is not among the nine priced add-ons - it appears only inside the custom-priced Enterprise bundle. https://buy.lavu.com/api/addons · retrieved 2026-08-08

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

Lavu runs a public storefront at shop.lavu.com (linked from the lavu.com homepage) with published outright prices across every required category: terminals - Complete POS Station Bundle, iPad Air 13in (M4) $2,374, Wi-Fi Handheld Bundle $1,270, Cellular Handheld $1,350; tablets - iPad Air 13in $799, iPad mini $499 / $749 cellular; KDS - Epson TrueOrder Kitchen Display System $1,119 (21.5in monitor with bump bar) to $1,262; printers - Epson receipt $275, kitchen $345, label $440; cash drawers - APG 16in $120; stands $240-$325; networking bundles $1,800-$4,140. The same catalogue is served as 51 one-time-priced SKUs by the buy.lavu.com purchase gateway. No lease, rental or financing option is offered on the storefront, and the string 'lease' appears zero times across all 250 support.lavu.com articles (the help-centre search API returns total 0 for the term). Hardware language throughout the docs is purchase language - 'the card readers you purchase through Lavu', 'the networking equipment that we sell'. Graded C: this is a first-party commerce catalogue, which is a pricing surface rather than documentation. https://shop.lavu.com/collections/ · retrieved 2026-08-08

Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator

commercial-hardware-not-locked

The KB's Equipment and Hardware category documents third-party, non-proprietary hardware as the normal path: a Compatible Star Micronics Printers list, nine Epson printer articles (TM-T88VII, TM-m30iii, wireless setup via Epson's own TM Utility app), APG Cash Drawer setup and dual-drawer configuration, Apple iPads and iPhones/iPods as the terminal, a Tor Rey L-EQ Bluetooth scale and a Socket Bluetooth scanner. Card acceptance is not single-vendor either - IDTech VP3300, Ingenico LANE 3000, Adyen NYC1, Verifone and PAX readers all have setup or troubleshooting articles - and Lavu documents operating without Lavu Pay ("If you are not signed up for Lavu Pay, the card readers you will use are also PCI compliant"). Caveat for the reader: readers are sourced through Lavu and no merchant-chosen gateway list is published, but the claim's bar is at least one non-proprietary option and Lavu clears it on the terminal, printers and cash drawer. https://support.lavu.com/en/knowledge/lavu-equipment-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

Control Panel - Transactions: the module 'allows to see and search through ALL of your restaurants orders', split into Orders and Payments pages, and under Export states 'You can export any or all of your orders from either of these pages', selecting individual rows or the whole page. Lavu Reports - How to Export a Report: 'Any report within Lavu can be exported into a CSV file... Similar steps can be followed for reports in the Transactions and Manage Time Cards pages', which covers labour via the Time Card reports, line items via Sales by Item and Modifier Usage, and payments via the End of Day and Bank Deposit reports. Inventory Import and Export and Menu Export / Import cover the reference data. Both routes are in-product, self-serve from the Control Panel, with no fee or support ticket mentioned. Independently, api.lavu.com/docs/swagger.json exposes GET /v1/customer/orders/, /orders/{id}/checks/, /checks/{id}/payments/, /orders/{id}/items/ and /items/{id}/modifiers-used/ under OAuth 2, so the transactional record is also machine-readable; the 26-path spec has no labour or time-card resource, which is why the CSV route is the one cited for labour. https://support.lavu.com/en/knowledge/control-panel-transactions · retrieved 2026-08-08

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 machine-readable: Reports > V1 Reports > Special > Customer Export (with a matching CSV Customer Import). Shortfalls: loyalty point balances and gift-card balances are only viewable and adjustable per individual card (with per-card history) - no documented bulk export of the loyalty ledger or outstanding gift liability - and the ToS disclaims post-termination extraction: Lavu 'has no obligation to retain, provide access to, or allow extraction of User Content or User Data post-termination' and 'may delete all User Content and User Data immediately upon termination'. https://support.lavu.com/en/knowledge/customer-management · retrieved 2026-08-05

Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator

commercial-post-termination-export-window

Same clause, checked for this proposition on verification: the ToS permits immediate deletion on termination and disclaims any obligation to allow extraction. A retrieval window is not merely unpublished — the contract reserves the right to eliminate it. https://lavu.com/terms-of-service/ · retrieved 2026-08-02 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

Verified verbatim: "You grant Lavu a perpetual, irrevocable, worldwide, royalty-free, nonexclusive, fully sublicensable license to use, reproduce, modify, distribute, display, perform, create derivative works from, and incorporate your User Content into Lavu Products or other works for any purpose, including marketing, product development, AI training, or promotion, without compensation or further permission." No merchant-ownership statement and no constraint on vendor reuse. https://lavu.com/terms-of-service/ · 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

Hardware-encrypted card entry is documented - "using properly encrypted card readers", and for Lavu Pay merchants "we will ensure that you remain PCI compliant through your card reader and your CardConnect account" - but the scope-reduction half of the claim is contradicted by Lavu's own instructions for the CardPointe PCI questionnaire: "Q: Your Point-to-point Encryption system? A: No", followed by a full guided assessment covering payment application type, remote access, printed card data and information security policy. No validated P2PE listing, no tokenization architecture and no SAQ type (A, A-EP, P2PE-HW or otherwise) is named anywhere in the help centre. https://support.lavu.com/en/knowledge/cardpointe-pci-compliance · retrieved 2026-08-09 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

Source code of Lavu's live first-party Control Panel login (cp.poslavu.com, React SPA; public unauthenticated chunk main.f9caaa32.chunk.js, retrieved 2026-09-13). This is minified client code, not documentation. What it shows: the login form posts username and password with source "cp3". If the returned user has accessLevel 4 and enableTwoFactorAuth equal to "1" (the code tests `4!==A.user.accessLevel||"1"!==A.user.enableTwoFactorAuth`), the login stops and asks for a one-time code. It requires a mobile number ("Mobile number is required") and shows a required "2FA Code" field ("Please enter Verification Code Sent to Mobile"). The code expires after 300 seconds ("Sorry, Verification Code Expired. Please resend Verification Code.") and can be re-sent with "Resend 2FA". The code is sent by SMS through Twilio: the error strings include "Message was not accepted by Twilio" and "Too many SMS requests. Please try again after {retry_after_minutes} minutes". The code is then checked at /mfa/twoFactor. The Users module (chunk 46.5c50b1b0.chunk.js) labels access levels with split strings: "Level 4 -" / " Multi-Location Owner" / "Full Access to update multiple locations.", and "Level 3 -" / " Owner" / "Access to Control Panel, back end's menu and the ability to make any necessary changes, access to the reports, inventory, user info, management area, and more." SHORTFALLS: (1) The second factor is conditional. It depends on a per-user server flag and appears only on the accessLevel-4 branch. The client offers no code-entry step to a Level 3 Owner, who has full single-location Control Panel access. A separate server `mfa_error` response on the first login request is handled, but every branch of it only shows an error and resets the form. This is not MFA for all back-office access, and the bundle does not show the flag's default or where it is set. (2) The only factor is an SMS one-time code. (3) There is no PCI DSS v4.0/4.0.1 framing and nothing on payment-page script integrity (Req 6.4.3/11.6.1). The first-party chunks have zero case-insensitive whole-word hits for `pci`, and zero for `4.0.1`, `6.4.3`, `11.6.1`, `subresource`, `script integrity` or `content-security-policy`. In the 40 archived Lavu PDF texts, PCI appears only as a generic explainer in the Beginner's Guide and one sentence in the self-ordering kiosk article ("Some kiosks offer PCI compliance"). Nothing covers POS-terminal login MFA. Date caveat: this is the bundle live on 2026-09-13 and says nothing about when the 2FA branch shipped. https://cp.poslavu.com/static/js/main.f9caaa32.chunk.js · retrieved 2026-09-13 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

Privacy policy documents an email/phone rights process (delete, correct, access, portability) via support@lavu.com, with CCPA requests limited to one per customer per year. No in-product operator tooling for guest DSARs and no published DPA. https://lavu.com/privacy-policy/ · retrieved 2026-08-01

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

Positive absence at both ends of the claim. Lavu Kiosk - Basic Customization enumerates the kiosk's entire settings surface - theme colour by hex, tip allowance, idle and start-page imagery (standard, menu carousel or custom image), Pickup and Dine-In dining options, order timeout duration, receipt printer, payment gateway, and the checkout fields, of which only the guest's name is mandatory - and no tactile keypad, audio or other non-visual access mode appears in it. On the publication half, the 4,844-URL first-party sitemap census across lavu.com, support.lavu.com and shop.lavu.com contains no accessibility, VPAT or ACR page of any kind; the only compliance documents Lavu publishes are the privacy policy and the terms. https://support.lavu.com/en/knowledge/lavu-kiosk-basic-customization · retrieved 2026-09-04 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

Lavu operates a cash-discount program, not surcharging, so the claim’s automatic debit and prepaid exclusion is structurally moot rather than satisfied. Receipt disclosure is documented — the support article shows both totals on the printed check — but menu-board disclosure is only restated as a federal requirement, not implemented in product. Shortfall: US-only, Lavu Pay only, admin-enabled, and no surcharging product exists. https://support.lavu.com/en/knowledge/cash-discount-program · retrieved 2026-08-02 adversarially verified