Restaurant365

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

No POS menu engine; R365 holds recipe/item cost records only. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

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

R365 is not a POS and holds no modifier price matrix. Menu items and modifiers are imported from the connected POS ("Menu item records are automatically created once the POS integration has been completed. R365 will automatically import each menu item that appears in your POS."), and the record's only price field is informational: "Estimated Price - The estimated price for the menu item. Informational only." The nearest feature, POS Menu Item Modifier Management (beta), does concatenate parent item + modifier + size into new R365 menu items, but explicitly "to ensure the accuracy of recipes and actual usage for POS modifiers" and so that "different recipes [can] be linked for each menu item/modifier combination" - recipe costing and depletion, never price. Parent/size modifier pricing belongs to the connected POS. https://docs.restaurant365.com/docs/pos-modifier-management · retrieved 2026-08-08

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

menu-pricing-fractional-placement

No fractional or sectioned modifier placement in R365, and none is possible: modifiers arrive as imported POS ticket records ("a Modifier ... is attached to another item on a POS ticket - for example, a sauce, a size selection, or a topping"), and POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." The POS Integrations List enumerates, per POS system, the complete set of R365 integration capabilities with explicit "Supported"/"Not Supported" lists: sales detail, labor, intraday polling, schedule writeback, till management, menu item modifier management, POS employee management. No menu, price, availability or card-acceptance capability appears anywhere in that matrix. Half-and-half handling is a function of the connected POS. https://docs.restaurant365.com/docs/integration-documentation · retrieved 2026-08-08

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

R365 exposes no half-and-half pricing rule of any kind; the string "half and half" does not occur anywhere in the 2,366-page documentation corpus. Menu items are imported from the POS and their price field is "Informational only"; POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/menu-items-menu-item-links · retrieved 2026-08-08

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

No modifier quantity tiers or price multipliers in R365. Toppings appear in the docs only in the glossary definition of an imported POS modifier. The menu item record's only price field is under Costing: "Estimated Price - The estimated price for the menu item. Informational only." The POS Integrations List enumerates, per POS system, the complete set of R365 integration capabilities with explicit "Supported"/"Not Supported" lists: sales detail, labor, intraday polling, schedule writeback, till management, menu item modifier management, POS employee management. No menu, price, availability or card-acceptance capability appears anywhere in that matrix. https://docs.restaurant365.com/docs/menu-items-menu-item-links · retrieved 2026-08-08

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

R365 has no price grid across variant axes. Size is recognised only as an imported POS modifier, and POS Menu Item Modifier Management (beta) concatenates size into new R365 menu items purely so that "different recipes [can] be linked for each menu item/modifier combination, and ensures accurate depletion of ingredients". The resulting records carry only "Estimated Cost", "Estimated Price" and "Target Profit %", all marked "Informational only". https://docs.restaurant365.com/docs/pos-modifier-management · 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

No included-modifier allowance or overage pricing in R365. The menu item record's only price field is under Costing: "Estimated Price - The estimated price for the menu item. Informational only." R365 ingests finished POS ticket lines; POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/menu-items-menu-item-links · retrieved 2026-08-08

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

R365 does not build combos. Combos appear in the documentation only as an accounting nuance on imported data - discount deduplication "uses the absolute menu price of negative-price combo items to calculate the discount payment amount" - i.e. R365 reads combo components the POS already priced. POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/integration-documentation · retrieved 2026-08-08

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

R365 presents no order-entry surface and therefore no suggestive-sell prompts; "upsell" does not occur in the documentation corpus, and The POS Integrations List enumerates, per POS system, the complete set of R365 integration capabilities with explicit "Supported"/"Not Supported" lists: sales detail, labor, intraday polling, schedule writeback, till management, menu item modifier management, POS employee management. No menu, price, availability or card-acceptance capability appears anywhere in that matrix. R365's menu engagement is analytical - the Menu Price Analysis report "calculates a variance and price needed to hit the target percentage" but changes nothing in the POS. https://docs.restaurant365.com/docs/pos-integrations-list · retrieved 2026-08-08

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

R365 performs no availability writeback. POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." The only writeback paths R365 documents anywhere are Schedule Writeback and POS Employee Management (beta), both enumerated in the Add On Integrations list and both tracked per POS in the integrations matrix; no 86, availability or menu channel is among them. https://docs.restaurant365.com/docs/integration-documentation · retrieved 2026-08-08

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

No per-item countdown or auto-86 in R365; "countdown" does not occur in the documentation corpus. R365 polls the POS after close of day (and optionally intraday, which "does not generate or update the DSS") and does not write back availability. POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/integration-documentation · retrieved 2026-08-08

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

R365 has day parts, but scoped to labour and reporting, not to menus. Day parts groups "define the time segments (such as Breakfast, Lunch, or Dinner) used throughout scheduling, forecasting, reporting, and task management" - an enumeration that does not include menus, items or prices - and they are configured under Administration > Location Hours. Menu and price scheduling belongs to the connected POS. https://docs.restaurant365.com/docs/day-part-settings · retrieved 2026-08-08

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

No price books in R365; the phrase does not occur in the corpus. Price exists on the menu item record only as "Estimated Price ... Informational only", with no channel dimension, and POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/menu-items-menu-item-links · retrieved 2026-08-08

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

No dual pricing or cash discount in R365 at the menu level. The corpus contains zero occurrences of "dual pricing", "cash discount" or "surcharge", R365 stores one informational price per menu item, and it operates no POS, kiosk or online ordering surface on which a second price could be displayed - "online ordering" appears only as an employee-attribution setting for tip distribution. https://docs.restaurant365.com/docs/menu-items-menu-item-links · retrieved 2026-08-08

Menu changes can be staged as an effective-dated version, previewed before publish, and rolled back to a prior version after publish. differentiator

menu-pricing-versioning-effective-dates

Effective-dated staging exists, but only for purchase cost, and neither preview nor rollback exists anywhere. The vendor item record carries an Effective Date on the contract price — "The date that the Contract Price will be active for the vendor item." — and "Fields on the vendor item record will only be updated when the effective date for the order guide is reached, or if the effective date has already passed when the order guide is imported." Currency conversion factors are effective-dated the same way. That is a future-dated cost change, not a menu version: R365 holds no menu price of its own (its menu-item price field is informational only), and across the vendor's complete published documentation — 2,629 pages taken from the docs.restaurant365.com llms.txt index and sitemap on 2026-09-10, 18.4M characters — the tokens `rollback` and `roll back` occur zero times and no staged-publish or restore-a-prior-version flow is described for an item, recipe or price record. Positive controls run in the same pass over the same corpus: `Restaurant365` matched in all 2,629 files, `inventory` in 531, `template` in 355. https://docs.restaurant365.com/docs/new-vendor-item-record · retrieved 2026-09-10

Supports a central corporate menu template pushed to locations with field-level governance controlling which attributes a location may override. differentiator

menu-pricing-franchise-hierarchy

Recipes and portions standardized across locations with central commissary catalogs — recipe governance, not POS menu governance. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

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

Should move up to at least partial: allergen tracking at the recipe level is documented in the public docs (allergens tracked within recipes for guests with dietary restrictions). Nutrition values and any guest-facing publication path remain undocumented, so partial is the correct landing spot, not full yes. https://docs.restaurant365.com/llms.txt · retrieved 2026-08-01 adversarially verified

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

Menu Item Analysis draws item Cost as "the cost of each menu item from its linked recipe in R365" and computes Margin as "the difference between the price and the cost," alongside Cost %, Theoretical Cost and Profit per item. The linkage is established during onboarding — Phase 4: Recipes covers mapping recipes to POS menu items for COGS tracking — and the Recipe record carries ingredients, cost, prep time, cook time and shelf life. Recipe Flow and Build Out documents yield, prep and menu-item recipe types. https://docs.restaurant365.com/docs/menu-item-analysis · retrieved 2026-08-02 adversarially verified

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

R365 pushes no menus to marketplaces. Third-party delivery appears in the documentation only as an accounting subject ("Third Party Delivery Services & House Accounts"), and The POS Integrations List enumerates, per POS system, the complete set of R365 integration capabilities with explicit "Supported"/"Not Supported" lists: sales detail, labor, intraday polling, schedule writeback, till management, menu item modifier management, POS employee management. No menu, price, availability or card-acceptance capability appears anywhere in that matrix. https://docs.restaurant365.com/docs/pos-integrations-list · retrieved 2026-08-08

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

menu-pricing-dynamic-pricing

No rule-based dynamic pricing in R365. Its rule engine is scoped to depletion: a menu item rule reads "WHEN Menu Item is [Menu Item] THEN deplete [Recipe]", and its THEN section "defines the depletion or replacement that executes when the WHEN conditions are met" - the available actions are enumerated and none of them price anything. https://docs.restaurant365.com/docs/menu-items-menu-item-links · 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

Not a POS — R365 neither provides nor restricts card acceptance. https://www.restaurant365.com/partner-category/pos/ · retrieved 2026-08-01

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

payments-published-rates

No card acquiring product, so no card rates exist. https://www.restaurant365.com/r365-payments/ · 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

R365 does not accept card payments, so it stores no cash/card price pair and prints no guest check. R365 Payments Service Overview: the service "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - it is accounts-payable vendor disbursement, not card acceptance. A full-text search of the 2,366-page docs.restaurant365.com corpus returns zero occurrences of EMV, NFC, contactless, Tap to Pay, pay at table, card reader, terminal, merchant account, surcharge, cash discount, dual pricing or store-and-forward. https://docs.restaurant365.com/docs/r365-payments-service-category · retrieved 2026-08-08

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

R365 operates no surcharging engine because it does not accept cards. R365 Payments Service Overview: the service "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - it is accounts-payable vendor disbursement, not card acceptance. The word "surcharge" does not occur in the 2,366-page corpus; the sole card-fee mechanic documented is a payroll one - a tip automation rule can "withhold a percentage of POS card tips ... to cover credit card processing fees", which the POS's processor charged. https://docs.restaurant365.com/docs/r365-payments-service-category · retrieved 2026-08-08

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

payments-emv-nfc

R365 sells no payment terminals. R365 Payments Service Overview: the service "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - it is accounts-payable vendor disbursement, not card acceptance. R365's own glossary defines the POS as "a system used by businesses to process sales transactions and manage customer payments. Connected to R365 through a POS integration." A full-text search of the 2,366-page docs.restaurant365.com corpus returns zero occurrences of EMV, NFC, contactless, Tap to Pay, pay at table, card reader, terminal, merchant account, surcharge, cash discount, dual pricing or store-and-forward. https://docs.restaurant365.com/docs/r365-payments-service-category · retrieved 2026-08-08

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

No tap-to-pay on phone. R365's mobile apps are operations tools (Smart Ops: sales review, inventory counts, scheduling, approvals); they take no payments. R365 Payments Service Overview: the service "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - it is accounts-payable vendor disbursement, not card acceptance. A full-text search of the 2,366-page docs.restaurant365.com corpus returns zero occurrences of EMV, NFC, contactless, Tap to Pay, pay at table, card reader, terminal, merchant account, surcharge, cash discount, dual pricing or store-and-forward. https://docs.restaurant365.com/docs/r365-payments-service-category · retrieved 2026-08-08

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

R365 ships no handheld and takes no payment. R365 Payments Service Overview: the service "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - it is accounts-payable vendor disbursement, not card acceptance. Its per-POS integration matrix enumerates only data-ingest and two writeback functions; no payment capability appears in it. Pay-at-table is a function of the connected POS, which R365's glossary defines as the system that "manage[s] customer payments". https://docs.restaurant365.com/docs/r365-payments-service-category · retrieved 2026-08-08

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

No guest-facing check payment in R365; "QR code" does not occur in the corpus and R365 has no check to close - it ingests completed sales tickets after the POS close of day. POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." R365 Payments Service Overview: the service "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - it is accounts-payable vendor disbursement, not card acceptance. https://docs.restaurant365.com/docs/integration-documentation · retrieved 2026-08-08

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

Tip capture and adjustment happen in the POS; R365 consumes the result. Tip Automation "uses rules to create a distribution pool of card and cash tips declared by employees in the POS", then distributes them as 'Tips' earnings on the Daily Sales Summary for payroll. There is no authorisation, batch or adjust window in R365 because it holds no card transactions. https://docs.restaurant365.com/docs/tip-automation-category · retrieved 2026-08-08

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

Tip Automation is a configurable native pooling engine, not just a payroll passthrough. The Distributions Report documents the pool math — "contributor math is calculated first at the contributor level, and the pooled total then determines receiver allocations" — over two datasets, a Contributors table showing "what each employee contributed to the tip pool" and a Receivers table showing "what each employee received from the pool." Rules are configured separately (Tip Automation Rules), scoped by job title or service type, with both daily and weekly rule types. Dependency worth naming: the pool is built from card and cash tips declared in the third-party POS, so accuracy inherits that feed. https://docs.restaurant365.com/docs/tip-automation-distributions-report · retrieved 2026-08-02 adversarially verified

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

R365 captures no card payments at all, offline or online, so there is nothing to store and forward; the phrase does not occur in the corpus. R365 Payments Service Overview: the service "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - it is accounts-payable vendor disbursement, not card acceptance. R365 reaches the POS by scheduled polling over cloud API, local install or FTP, and POS Integration Overview: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/r365-payments-service-category · retrieved 2026-08-08

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

R365 Payments is vendor disbursement, not card acceptance: it "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)". Guest card authorization happens in the connected POS, which the POS Integration Overview calls the "source of record", so R365 has no stored offline transaction, no decline-on-reconnect event and no liability position to publish. https://docs.restaurant365.com/docs/r365-payments-service · retrieved 2026-08-08

First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.

payments-gift-cards

Gift cards exist in R365 only as accounting: "Gift Card | Used when customers pay using gift cards. Typically mapped to Unredeemed Gift Cards, a liability account. When a gift card is sold, revenue is not recognized until redeemed." R365 issues no cards, holds no card balances and provides no redemption endpoint - the balance it tracks is a GL liability moved by tenders the POS reports in the nightly import. https://docs.restaurant365.com/docs/payment-type-accounts-overview · retrieved 2026-08-08

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

payments-house-accounts

AR/customer invoicing exists (Customers Reports; commissary third-party sales) but this is accounting AR, not a POS house-account tab. https://help.restaurant365.net/support/solutions · retrieved 2026-08-01

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

R365 has no check-settlement surface to split. "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS"; sales tickets and their payment types are created by import from the POS. The second doc host, help.restaurant365.net, returns "No results found" for "split tender". https://docs.restaurant365.com/docs/pos-integration · retrieved 2026-08-08

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

Voids and discounts reach R365 only as imported reporting measures ("Void Amount", "Void Qty" attributes on the sales dashboards). The POS Integration Overview states R365 "does not modify the information stored in the POS", and on the one operational control it does touch says "these enforcement settings are managed entirely within the POS". Approver-level authorization and the audit trail for voids/refunds/no-sales are POS functions; R365 documents no override prompt of its own over guest checks. https://docs.restaurant365.com/docs/pos-integration · retrieved 2026-08-08

In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator

payments-chargeback-tooling

R365's "Automated Dispute Resolution" is vendor invoice/credit-memo recovery, not card chargebacks. https://www.restaurant365.com/accounting/automated-dispute-resolution/ · retrieved 2026-08-01

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

The only payment credentials R365 stores are vendor-side: R365 Payments assigns a check/ACH/vCard method to a Vendor record for outbound AP disbursement. There is no guest or customer profile in the product - the public API exposes no guest/customer resource - so there is nothing to hold a tokenized guest card against, and R365 never touches a guest PAN. https://docs.restaurant365.com/docs/r365-payments-service · retrieved 2026-08-08

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

payments-payout-timing

No merchant funding to publish a schedule for. R365 Payments is an outbound AP disbursement product, and its documentation enumerates the complete method set: "ACH payments can be processed in 3-4 banking days, depending on bank requirements", "Payments made by vCard are usually processed in 4 banking days", and checks "generally take about 7-10 banking days from submission until the vendor receives funds" (about 5-8 with the no-hold option). No card-acceptance settlement, deposit schedule, or next-day/instant funding option appears anywhere in the R365 Payments documentation set. https://docs.restaurant365.com/docs/r365-payments-payment-methods.md · retrieved 2026-08-08

A single account can route settlement funds to different bank accounts per location or legal entity (separate MIDs or split settlement) under unified reporting. differentiator

payments-multi-entity-routing

Multi-entity accounting with per-entity bank connections for AP/reconciliation; card settlement routing is out of scope. https://www.restaurant365.com/accounting/banking/ · retrieved 2026-08-01

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

R365 publishes no PCI posture of any kind and has no card-entry surface to attest for. Tokenised over the complete published corpus assembled 2026-09-10 — 2,629 documentation pages, 2,479 marketing documents from the WordPress REST census, 217 Freshdesk help articles, 36 contract PDFs and 132 status-page incident reports, 32.6M characters — `P2PE` occurs 0 times, `SAQ` 0 times, `Attestation of Compliance` 0 times and `PCI DSS` exactly once, in an R365 blog post explaining the standard to restaurant readers rather than asserting anything about R365. A Vanta-hosted trust centre exists at trust.restaurant365.com but serves a single React shell for every path including /robots.txt and a fabricated filename, and its data host app.vanta.com bars all crawlers host-wide, so its contents were not read. https://docs.restaurant365.com/llms.txt · retrieved 2026-09-10

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

Partial stands, but the stated reasoning is wrong and understates R365. It is documented: R365 ships its own first-party "R365 Timeclock" with per-employee Time Clock IDs valid on all configured time clock devices at the employee's locations, plus a Time Clock Configuration screen. It is a native R365 punch surface — just not a POS terminal, which is the only reason this cell stays partial. Confidence should be "documented", not "inferred". https://docs.restaurant365.com/docs/r365-timeclock · retrieved 2026-08-01 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

R365 ships a Time Clock device app and a punch pipeline, and neither captures an image. Tokenised over the complete 2,629-page product documentation set (18.4M characters, taken from the publisher's own llms.txt index on 2026-09-10): `photo at punch` 0, `punch photo` 0, `selfie` 0, `facial recognition` 0, `biometric` 0, `fingerprint` 0. The same terms appear only outside the product documentation and only about other companies — a fingerprint and iris terminal called Mantra mTerminal100 in the partner directory, and comparison blog posts. Positive control run in the same pass over the same corpus: `punch` matched in 115 of the 2,629 files. https://docs.restaurant365.com/docs/configure-a-timeclock-device · retrieved 2026-09-10

Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.

labor-geofenced-mobile-punch

Tokenised over the complete 2,629-page product documentation set on 2026-09-10 (18.4M characters): `geofence` 0, `geofencing` 0, `geofenced` 0, `geo-fence` 0, `GPS` 0, `location validation` 0, `location services` 0. Every hit for those terms in the wider corpus is in a marketing blog comparing other vendors' scheduling apps (ZoomShift, When I Work, Toast Scheduling) — the absence is bounded to Restaurant365's own documentation, not to the word. One trap was caught and excluded: a Document360 CDN image filename, image-YFXAGPSJ.png, contains the letters GPS and is matched by a substring search but not by the tokenised matcher used here. R365 punching is tied to a provisioned Time Clock device rather than validated against a location. https://docs.restaurant365.com/docs/configure-a-timeclock-device · retrieved 2026-09-10

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

Documented in the vendor's own Time Clock device article: "Employees can continue to clock in and out while the device is offline. Punches are stored locally on the device and sync to R365 automatically when the connection is restored. No manual action is needed to recover punch data." The failure path is documented separately: a punch that does not reach the Time Clock service stays in the Punch Action Log with a status of Failed or Blocked and can be resynced individually or in bulk, and the article warns that a Sent status "confirms delivery to the Timeclock service, not processing into the Timecard." https://docs.restaurant365.com/docs/configure-a-timeclock-device · retrieved 2026-09-10

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

Publicly documented and granular: a hierarchical permission tree ("Permissions ... determine which pages, records, and features the User is able to view and which actions they can take"), default R365 roles plus Custom User Roles, separate Report Roles gating individual reports, and location scoping via "All Location", "Specific Locations", "By Legal Entity" or "By Location Reporting Category". Individual record types also ship per-object "Overview & Security" doc pages. https://docs.restaurant365.com/docs/user-setup-security-and-location-access · retrieved 2026-08-01 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

Punch edits are audited end to end: an edit notifies the employee, the employee acknowledges, and the acknowledgement lands in the Time Punches Audit Log and the Punch Audit Report, which surfaces discrepancies, edits and missing entries. Scope caveat — this covers time-punch overrides only; POS-side comp/void overrides are not R365's to audit. https://docs.restaurant365.com/docs/punch-audit-report · retrieved 2026-08-01 adversarially verified

Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator

labor-native-scheduling

Scheduling Overview documents a native module covering "schedule creation, shift management, employee requests, publishing, labor goals, and security roles" — a Scheduling Calendar for building and assigning shifts, Scheduler Templates and Shift Templates, blackout days, announcements, time-off management, a Manager Queue for approvals, and publishing to employees through the R365 Red App. Labor forecasting integrates when Smart Labor is enabled. The one add-on named on the page is Schedule Writeback, which pushes published schedules back to the POS — the scheduler itself is not gated. https://docs.restaurant365.com/docs/scheduling-module · retrieved 2026-08-02 adversarially verified

Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator

labor-demand-labor-forecast

SHORTFALL: requires the Smart Labor add-on. Docs: "Smart Labor is an add-on feature ... Enabling Smart Labor in your instance will include the additions of the Labor Matrix for constructing the Labor configuration specific to your Organization and Hourly Forecasting so that you can forecast the exact amount of Employees needed per hour each day." Adjusting Forecasts: "The labor forecast is calculated from the sales forecast and the location's Labor Matrix" — with no Labor Matrix configured, no labor forecast is produced. The base product publishes a weekly sales-and-labor projection into scheduling, but per-hour headcount recommendations are gated behind the paid add-on. https://docs.restaurant365.com/docs/smart-labor · retrieved 2026-08-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

Marketing-page sourcing for a real-time claim, with the dossier itself admitting "POS polling cadence not published". R365 owns no transaction source, so labor-vs-sales freshness is bounded by undocumented third-party POS polling intervals. Not supportable at yes. https://www.restaurant365.com/workforce/ · retrieved 2026-08-01 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

Marketing copy read as capability. Product docs describe scheduling "overtime warnings" — warnings, not a hard block at clock-in. The dossier's own note concedes blocking is undocumented, which is a partial by its own logic. https://docs.restaurant365.com/docs/scheduling-module · retrieved 2026-08-01 adversarially verified

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

"alerts for potential compliance issues, such as missed breaks or overtime"; per-state rule libraries and attestation prompts not documented. https://www.restaurant365.com/workforce/scheduling/ · retrieved 2026-08-01

Supports predictive-scheduling ordinances by tracking advance-notice deadlines for published schedules and calculating predictability pay owed for employer-initiated changes.

labor-fair-workweek-support

The Labor Rules Overview enumerates nine rule types, and the fringes of fair-workweek ordinances are genuinely covered: clopening penalties (within Split Rules) "define how penalties for clopening shifts are calculated and are triggered by the length of the break between two shifts on consecutive days", alongside Reporting Time Pay and Spread of Hours rules; the docs index also lists a Schedule Change Audit report ("List all schedule changes made after publishing, showing Event Type (Modified, Added, Removed, Swap)"). Named shortfall: neither of the claim's core mechanisms is documented — no tracking of advance-notice deadlines for published schedules and no predictability-pay calculation for employer-initiated changes. No such rule type appears in the enumerated list, and "fair workweek", "predictive" and "predictability" return zero hits across the full public docs index (llms.txt). The page also disclaims that rules are not verified against local laws. https://docs.restaurant365.com/docs/labor-rules-overview · 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

Minor Rules are a first-class labor-rule type, one of eight (Overtime, Break, Minor, Split, Tip Makeup, Spread of Hours, Reporting Time Pay, Shift Differential). Docs: "Minor rules define shift length thresholds and shift hour windows for set date ranges based on the employee's age and if school is in session." Configuration carries an Age Group, Hrs/Day and Hrs/Week for both in-school and off-school periods, Overnight Start / Overnight End prohibited windows, and School Year date ranges (https://docs.restaurant365.com/docs/admin-page-minor-rules). Violations flagged are Daily Hour Limits, Weekly Hour Limits, Total Days Per Week Limits and Overnight Hour Restrictions. SHORTFALL, two parts: (1) scheduling-side only — warnings surface in the New Shift form, the Publish Check modal and the Manager Queue on shift trades/claims; no clock-in, time-clock or punch-side enforcement is documented anywhere in the Minor Rules or R365 Time Clock pages, so the claim's "at both scheduling and clock-in" half is unmet. (2) Advisory, not enforcing — the system "will notify Users when a Shift violates a Minor Rule but will not prevent the User from creating and publishing Shifts", and warnings carry an Ignore action. R365 also states it does not check user-configured rules against local labor law; the rule tables are customer-authored, not a maintained jurisdictional library. https://docs.restaurant365.com/docs/schedule-calendar-minor-rules · retrieved 2026-08-04

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

Upheld, but the marketing sourcing was inadequate and the docs substantiate it more precisely: rules build a distribution pool from card and cash tips declared in the POS, evaluate every employee who worked in the rule window as contributor and/or receiver by job, distribute evenly or by percentage, and can be scoped to selected hours, days and contributing jobs, calculated daily or weekly. Note the dependency the marketing page hides — tips originate as POS declarations, so accuracy inherits the third-party POS feed. https://docs.restaurant365.com/docs/tip-automation · retrieved 2026-08-01 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

Documented: distributions carry an approval step, post as 'Tips' earnings on the DSS, are attributable per contributor/receiver by rule window and job, and are downloadable as .csv (or pushed automatically to payroll when Workforce is enabled). https://docs.restaurant365.com/docs/tip-automation · retrieved 2026-08-01 adversarially verified

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

KB carries W-2 tip-box and Form 8027 articles; TY2026 Box 12 code TP / Box 14b and occupation-code specifics are not documented. https://help.restaurant365.net/support/search?term=tip · retrieved 2026-08-01 · not refetchable · site policy · graded B when read

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

"First-party" is asserted, not shown. The payroll page says only "Restaurant365 automates payroll tax calculations, filings, and payments at the federal, state, and local levels" — it names no filing agent, no EIN-of-record model, and never states whether an embedded provider underlies it; targeted searching surfaced no vendor statement either way. The product plainly exists and is a monitored status component, but whether the tax engine and filings are R365's own is undocumented — exactly the marketing-as-capability read the brief warns against. https://www.restaurant365.com/payroll-hr/payroll/ · retrieved 2026-08-01 adversarially verified

Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).

labor-payroll-export-formats

They are enumerated: the public docs index lists payroll integrations/export formats for ADP, Paychex, Paycom and APS. Tip distributions are additionally downloadable as .csv for import to an external payroll system. https://docs.restaurant365.com/llms.txt · retrieved 2026-08-01 adversarially verified

Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator

labor-shift-swap-workflow

Trade Shifts: an employee submits a trade request from the R365 app, selecting the shift to give up and the shift to take. Eligibility is enforced — the counterparty must work "at the same restaurant location", have "the same job on the shift", and be "available during the shift". Two-stage approval: "The other employee will then approve or deny their request to trade"; "If approved, the request will submit for manager approval." A denial at either stage leaves both original assignments intact. Manager-side requests land in the Manager Queue alongside shift claims, time-off and availability changes. Overtime consequences of a trade are not documented as a blocking check. https://docs.restaurant365.com/docs/r365-app-trading-shifts · retrieved 2026-08-02 adversarially verified

Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.

labor-digital-onboarding-i9

"New hires can complete W-4 and I-9 forms digitally" and "Verify work eligibility instantly to meet federal requirements"; E-Verify is not named. https://www.restaurant365.com/payroll-hr/onboarding/ · retrieved 2026-08-01

Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator

labor-server-performance-metrics

Sales/Labor/Operational Analysis report libraries exist; per-server attachment and void/comp rates depend on the POS feed and are not enumerated. https://help.restaurant365.net/support/solutions · retrieved 2026-08-01

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

"Automate item and recipe costing" with standardized recipes across locations; sub-recipe nesting depth not stated publicly. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.

inventory-unit-conversion-yields

Implied by automated recipe costing from purchase invoices, but purchase/recipe/count unit conversion and yield factors are not documented publicly.

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

Actual vs Theoretical Analysis "compares the theoretical cost of certain inventory items or categories against actual data, in terms of both quantities and dollar amounts," and "calculates theoretical usage using historical POS (point of sale) and PMIX (menu item) data." Shows beginning inventory, purchases, transfers, ending quantity, actual vs theoretical quantity and dollars, variance, waste and donations, with item-level drill-down and category sorting. A WEPT-framework troubleshooting page and an Actual vs. Theoretical Location Summary covering multiple locations sit alongside it. https://docs.restaurant365.com/docs/actual-vs-theoretical-analysis · retrieved 2026-08-02 adversarially verified

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 derives from POS sales polling into theoretical usage; near-real-time modifier-level depletion is not documented.

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

R365 tracks theoretical usage and on-hand counts but cannot act on them at the register: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." The article enumerates every add-on integration and the only writebacks to the POS are published schedules and, in beta, employee records - no item-availability path, and no channel connector at all. https://docs.restaurant365.com/docs/pos-integration · retrieved 2026-08-08

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

inventory-count-modes

Mobile counting with simultaneous multi-user counts is claimed; distinct full/spot/cycle modes with separate variance history are not documented. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.

inventory-mobile-count-offline

Barcode scanning is extensively documented: counts scanned via phone camera or external Bluetooth scanner, barcodes mapped to purchased items and recipes, add/delete barcodes, and barcode printing. Combined with the FAQ's offline count support this clears yes. https://docs.restaurant365.com/docs/barcode-scanning-inventory-counts · retrieved 2026-08-01 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

Upheld, but a partner marketing page was the wrong evidence for a weighted yes. Public docs list EDI integration for vendor invoice imports with error-identification tooling — that is the documentation-grade support this score needed. https://docs.restaurant365.com/llms.txt · retrieved 2026-08-01 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

AP Capture AI docs: "Capture AI reads each document, extracts available header and line-item details, and uses that data to prefill fields on the Draft Transaction screen," running OCR to populate Vendor, Location, Invoice Number, Invoice Total and Payment Terms against existing records. Line-item extraction is explicit. Two caveats: settings are "available only when AP Capture AI is enabled" and entitlement is not published; and the separately-named AP Capture Pro is not OCR at all but "an additional service that R365 offers" where "users can rely on the R365 Data Entry Team to enter and review AP transactions" within 24 hours — a human keying service, priced via Sales. https://docs.restaurant365.com/docs/ap-capture-ai · retrieved 2026-08-02 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

SHORTFALL: report-only, with no threshold-triggered alerting. Item Price Change Analysis compares "the purchase price as of the start date of the report versus the average purchase price over the date range of the report" and shows "the COGS impact the higher/lower price has made per item" across multiple vendors on one report. The only threshold is a "Percent Diff" report parameter the user sets when running it — no documented automatic trigger, notification or subscription on a price breach, and no contracted-price object to compare a received price against. A companion Item Price Verification report identifies price variance between locations, also on demand. https://docs.restaurant365.com/docs/item-price-change-analysis · 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

Suggested Ordering states "Par must first be established" and publishes the formula: "Ending inventory + AP +/- Transfers - Sold Quantity = On hand. On hand - Par = Suggested Order." The forecast-driven mode is documented separately on PO Suggestion Evaluation: "System-suggested order quantity for the item on the PO, based on consumption days, buffer days, and usage data," estimating need from "historical/menu-item usage per $1,000 in sales and forecasted sales for that period," netted against on-hand at the order date and overridable per location. https://radar.help.restaurant365.com/support/solutions/articles/12000084047-suggested-ordering · retrieved 2026-08-02 adversarially verified

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

inventory-waste-logging

"Protect margins by spotting and reducing waste"; structured reason codes and waste cost reported separately from variance are not documented. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

Supports inter-location inventory transfers as a two-sided transaction crediting the sending location and debiting the receiving location, with an in-transit or approval state.

inventory-transfers

"Control inventory with accurate transfer tracking"; two-sided/in-transit states not detailed. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

Supports a commissary/central kitchen model where one location produces prep items and issues or sells them to other locations at a computed transfer cost.

inventory-commissary

Dedicated commissary module: catalog management, standardized recipes across locations, and selling commissary items to third parties. https://www.restaurant365.com/inventory/commissary/ · retrieved 2026-08-01

Captures lot/batch numbers at receiving and links them through production to sales or transfers, enabling a backward and forward recall trace.

inventory-lot-traceability

No lot or batch identity exists anywhere in the product. Tokenised over the complete published corpus on 2026-09-10 (5,592 files, 32.6M characters): `lot number` 0, `lot code` 0, `batch number` 0, `FSMA` 0, `recall trace` 0, `forward trace` 0; `traceability` 3 hits, none about food — a chart-of-accounts import, a transaction-voiding article and one blog. Confirmed independently against the machine-readable contract: the 186 R365 Developer Hub reference pages published on docs.restaurant365.com each embed a complete OpenAPI fragment, and across the 318 distinct component schemas and 509 distinct property names extracted from them, no property name contains lot, batch or expir. 245 of those 318 schemas set additionalProperties to false, so for those objects the field list is a real ceiling and not merely what happens to be documented. https://docs.restaurant365.com/llms.txt · retrieved 2026-09-10

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

Shelf life is tracked on prepped items and drives prep planning, but nothing is dated at receiving and no expiring-soon report exists. The prep recipe record carries a Shelf Life field — "Length of time after prep is completed before the item must be discarded, as entered into the Days, Hours, and Minutes fields." — and a Prep for Shelf Life setting that "Determines whether shelf life is included in prep quantity calculations." The shortfall: over the complete published corpus on 2026-09-10 (32.6M characters), `use-by` appears 3 times and only in blog posts, and no expiration or use-by date is captured on a received purchased item; every expiring-soon hit is an employee-certification or memorised-AP-transaction notification, not a spoilage alert. https://docs.restaurant365.com/docs/prep-recipe-record · retrieved 2026-09-10

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

inventory-bar-partial-bottle

Delivered through two named, first-party-documented import integrations rather than natively. R365 publishes a setup and import procedure for Bar-i — "R365 is integrated with Bar-i for your beverage inventory needs." — and for Accubar — "R365 is integrated with Accubar for your beverage inventory needs." — each mapping the third-party liquid-inventory system's counted quantities onto R365 purchased items through a dedicated inventory count template, and the unit-of-measure model carries a Weight measure type alongside a worked Bottle 750 ML example. The shortfall: R365 itself weighs nothing. Over the complete published corpus on 2026-09-10, `partial bottle` occurs 0 times, `bottle weight` 0 and `scale integration` 0; there is no native scale device support and no bottle-fraction count unit. https://docs.restaurant365.com/docs/bar-i-count-import · retrieved 2026-09-10

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

R365 is itself the restaurant GL — COGS and AP invoice detail post natively with GL coding; positioned as a replacement for QuickBooks, NetSuite and Sage Intacct. https://www.restaurant365.com/accounting/ · retrieved 2026-08-01

Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator

inventory-native-not-partner

Inventory, recipes and costing are native modules of the same platform as the GL — R365 is the product POS vendors integrate to. https://www.restaurant365.com/inventory/ · retrieved 2026-08-01

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

Menu Item Analysis "shows the margin and quantities of menu items ranked against each other and returns a category that has a call to action associated with it." Columns: Item, Price, Cost, Margin, Cost %, Qty, Sales, Sales %, Priority, Theoretical Cost, Profit, Category. Cost is "the cost of each menu item from its linked recipe in R365"; Margin is "the difference between the price and the cost." Items classify as Star, Opportunity, Puzzle or Dog against profit-margin and popularity thresholds. A Menu Price Analysis report with target-variance calculations and an AI menu-engineering dashboard sit alongside it. https://docs.restaurant365.com/docs/menu-item-analysis · retrieved 2026-08-02 adversarially verified

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

"View operational and financial performance in real time, across every location, from one dashboard", plus an iOS/Android app included for all customers. https://www.restaurant365.com/accounting/financial-reporting/ · retrieved 2026-08-01

Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.

reporting-eod-closeout

Daily sales/cash journal entries from the POS feed plus a Cash Management module; a single canonical EOD document is not shown publicly. https://help.restaurant365.net/support/solutions · retrieved 2026-08-01

Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.

reporting-pmix-modifier-level

Sales report library covers item mix; modifier-level granularity depends on the connected POS and is not documented.

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

Operational Analysis reports cover discounts/comps from the POS feed; approver attribution originates in the POS.

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

Dedicated Cash Management module with a Banking Reports library. https://www.restaurant365.com/ · retrieved 2026-08-01

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

37-article Labor Reports plus 25-article Workforce Reports libraries in the public KB; labor-to-sales is the core workforce pitch. https://help.restaurant365.net/support/solutions · 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

Employee/department leaderboards claimed in AI Dashboards; full per-server attachment and tip-percentage scorecards not enumerated. https://www.restaurant365.com/inventory/ai-dashboards/ · retrieved 2026-08-01

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

Third-party delivery sales and fees can enter the P&L via integrations, but a native channel margin report net of commission is not documented.

Provides a consolidated multi-location report with side-by-side location comparison and drill-down from group total to a single location and then to an individual transaction. differentiator

reporting-multiloc-drilldown

SHORTFALL: side-by-side comparison is documented, in-report drill-through to a transaction is not. Multi-location comparison exists in several places — the Flash Report "shows summary information based on a single day's performance in one or multiple locations", a Location Comparison report "compares certain operation values on the P&L report from two or more restaurant locations", and the Actual vs. Theoretical Location Summary shows "the AvT at the location level across multiple locations" to "compare total food variance performance across all their locations in one place." But that page then instructs users to leave it for detail: "To view variance at the item category and item level, run the Actual vs. Theoretical Analysis or the Above-Store Actual vs. Theoretical Analysis." Both named dashboards are single-location — Operations Overview exposes only "the location currently displayed in the dashboard. Click to change the displayed location," and the Financial Dashboard "shows a location's financial standing." R365 Intelligence dashboards support drilling "down, up, or across attributes and select metrics", but no documentation confirms location as a drillable dimension or a path to an individual transaction. https://docs.restaurant365.com/docs/actual-vs-theoretical-location-summary · retrieved 2026-08-02 adversarially verified

Includes a self-service report builder letting a non-developer choose dimensions, measures, and filters and save the result, rather than only fixed canned reports. differentiator

reporting-custom-report-builder

Upheld, but a status-page component name is not capability evidence and should never have carried "documented" confidence. Real product docs exist: "Create and Modify Ad Hoc Reports", My Reports with location-group filtering, and Custom Financial Report templates shareable across instances. https://docs.restaurant365.com/docs/create-and-modify-ad-hoc-reports · retrieved 2026-08-01 adversarially verified

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

A monitored component name tells you a service exists, not what it does for a customer. No product documentation of subscription scheduling, recipients, formats or cadence was located. Downgrade until a docs page is produced. https://status.restaurant365.com/ · retrieved 2026-08-01 adversarially verified

Offers automated recurring bulk export of transaction-level raw data to a customer-controlled destination (S3, SFTP, Snowflake, BigQuery, or equivalent), not just manual CSV download. differentiator

reporting-raw-warehouse-export

Real, documented and schema-complete, but still gated to a beta cohort. Secure Data Share "provides direct, read-only access to Restaurant365 reporting data from an organization's Snowflake environment." It is established by R365 against Snowflake account details the customer supplies, and "Data is updated once a day, reflecting all activity from the previous day." — an automated recurring delivery into a customer-controlled warehouse, not a manual CSV. The published data dictionary covers 20 views including Sales, Product Mix, Payments, Labor Activity, Inventory Activity and General Ledger, each with column names, data types and descriptions; the Sales view carries location_id, business_date, 15/30/60-minute intervals, is_voided, quantity and amount. The shortfall, stated by the vendor on the same page: "This feature is in beta for select customers." https://docs.restaurant365.com/apidocs/snowflake-data-share-setup · retrieved 2026-09-10 adversarially verified

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

Object coverage and reference docs are public: Accounting, Inventory, Sales and Labor domains, ~68 endpoints, read AND write ("supports both reads and writes"), versioned path /public/v1/. Credentials still require a CSM request so it is not self-serve, but the capability is documented rather than merely referenced in partner marketing. https://docs.restaurant365.com/docs/r365-api · 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

R365 emits nothing. Its own manifest closes the enumeration: "R365 exposes three integration surfaces for building against the R365 platform." — the Public API, Secure Data Share and the Classic API — and all three are pull-only, the Classic API being explicitly read-only. Across the 154 operations and 318 schemas extracted from the 186 published OpenAPI reference pages there is no subscription, callback or event resource. Tokenised over the complete published corpus on 2026-09-10 (32.6M characters): `webhooks` 0, `callback URL` 0, `event subscription` 0, `signature verification` 0, and `webhook` exactly once — a feature line reading API and webhook access on an archived price list, in the top tier of the separately sold R365 employee-training product, not the back-office platform. https://docs.restaurant365.com/apidocs/r365-public-apis · retrieved 2026-09-10

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

reporting-api-not-upcharged

Where R365 has published a feature-by-package split, API access is a top-tier line and never a base-package one. The archived price list puts the core platform at Essential "$499 / month" and Professional "$749 / month" per location and lists no API line in either, while "API & webhook access" appears only in the $199 Premium tier of the separately priced training product, above "Integrations with partner APIs" at the $135 Advanced tier. The two newer data surfaces are gated by programme rather than by price — the Public API is a closed Early Adopter group whose own documentation says "Availability and pricing are subject to change.", and Secure Data Share is in beta for select customers. Nothing R365 publishes states that API access is included in a base subscription. Graded C: this is a pricing page, and it is the archived one — the live /pricing/ page carries no tier table at all, only a custom-quote form. https://www.restaurant365.com/pricing-archive/ · retrieved 2026-09-10

Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator

reporting-tier-paywall

The entry paid tier carries operational reporting; the analytical layer is a tier up. R365's archived price list gives Essential at "$499 / month" per location including "Financial Reporting", "Daily Sales & Labor Polling", Forecasting and "Actual Vs Theoretical Food Costing", and puts "Custom Financial Reporting" and "Financial Intelligence Dashboards" in Professional at "$749 / month". The gate is independently corroborated inside the product documentation, which states of the authentication settings that "MFA is only available as part of the R365 Professional Package". Graded C and not higher because the live /pricing/ page publishes no tier table at all — the split is readable only on the archived page — and because neither page is granular enough to say which side PMIX or a comps-and-voids audit falls on. https://www.restaurant365.com/pricing-archive/ · retrieved 2026-09-10

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

The claim asks the vendor to document a retention window, and R365 documents none. Tokenised over the complete published corpus on 2026-09-10 (5,592 files, 32.6M characters, comprising 2,629 documentation pages, 2,479 marketing documents, 217 help articles, 36 contract PDFs and 132 incident reports): `retention period` 0 hits, `36 months` 0, and every data-retention hit is about deleting or recreating a single Daily Sales Summary. The one published numeric limit is a request-size cap, not a horizon — "You can retrieve up to 31 days (one month) of sales data per request." — and the master subscription agreement's only statement on the subject is the opposite of a retention promise: "Restaurant365 shall delete all of the Customer's information, with the exception of any Aggregated Data, from the System the day after the effective date of termination." https://docs.restaurant365.com/llms.txt · retrieved 2026-09-10

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

Budget/forecast variance alerts, vendor price-change alerts and "catch costly errors across ops, accounting, and vendor activity"; user-configurable thresholds not documented. https://www.restaurant365.com/accounting/financial-reporting/ · 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

AI Dashboards: "Generate custom dashboards and visualizations from a simple text prompt" against the operator's own data. https://www.restaurant365.com/inventory/ai-dashboards/ · retrieved 2026-08-01

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

R365's deepest guest-level report is the Guest Check Transaction Detail, keyed to "the check number, cashier name, items sold, any discounts applied, the total amount of the charge, any change due, and the method of payment" - no guest identifier at all. Elsewhere "Guest Count" is an editable numeric field on the Daily Sales Summary imported from the POS. There is no loyalty, CRM or guest-profile record in the product or its public API, so new-versus-returning, frequency and lifetime-spend cohorts cannot be formed. https://docs.restaurant365.com/docs/guest-check-transaction-detail · retrieved 2026-08-08

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

System-generated from the location's own history, with six documented projection models: Smart Forecast (Current Year), "average sales by day of the week for the past 8 weeks"; Smart Forecast (YoY), prior-year actuals adjusted by the year-over-year daily trend; Last Week Actual; Last Year Actual; Customized, averaging manually selected projection dates; and Imported, where the "sales projection was not system-generated." Adjusting Forecasts confirms "the system automatically generates the initial sales forecast using the location's default projection model." Sub-day granularity is documented — Smart Labor's forecast reads "the amount of Sales made each Operating Hour of each week day for the past eight weeks," and Daily Forecasting offers View by Hour, 30 Minutes and 15 Minutes. Consumption is documented on both sides: publishing "finalizes sales and labor projections for the selected week" into scheduling, and PO Suggestion Evaluation sizes orders from "forecasted sales for that period." Forecast Analysis and the Forecast Report expose Forecast vs Actual Variance against current, prior and two-years-prior actuals. https://docs.restaurant365.com/docs/weekly-forecasting-projection-models-and-forecast-metrics · retrieved 2026-08-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

Tip automation plus KB coverage of W-2 tip boxes and Form 8027 setup. https://www.restaurant365.com/workforce/tip-automation/ · retrieved 2026-08-01

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

Multi-entity/legal-entity plus location structures are core to the accounting model; a named three-level hierarchy object is not documented publicly. https://www.restaurant365.com/accounting/ · retrieved 2026-08-01

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

No POS menu publishing; recipe and order-guide standardization is the analogue. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

Corporate menu items expose per-field override rules so a location can change some attributes (e.g. price, availability) while corporate locks others (e.g. name, image, recipe), and locked fields are not editable at store level. differentiator

multi-location-local-override-policy

R365 has no corporate-to-store menu publishing surface, so there is no per-field override or lock. The Menu Items article states menu item records are "automatically created once the POS integration has been completed. R365 will automatically import each menu item that appears in your POS", and the record's editable fields are Display Name, Estimated Cost, Price and Target Margin - analysis attributes on an imported mirror. The POS Integration Overview adds that "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." Menu governance in R365 runs POS-to-R365, never R365-to-store. https://docs.restaurant365.com/docs/menu-items-menu-item-links · retrieved 2026-08-08

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

No menu price tiers or zones. The Menu Item record carries a single Price field alongside Estimated Cost and Target Margin and is created by import ("R365 will automatically import each menu item that appears in your POS"); price by location surfaces only in reporting (Menu Price Analysis, Item Price Change Analysis) and in vendor/purchase pricing, where "R365 updates the vendor item price whenever an invoice containing the vendor item is completed or approved at any location. This updated price will be used across all locations." Channel and daypart menu pricing are set in the connected POS, and "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/menu-items-menu-item-links · retrieved 2026-08-08

Menu, price, and promo changes can be scheduled to activate at a future date/time interpreted in each target location's own timezone, and can be rolled back after activation. differentiator

multi-location-scheduled-publish

No menu, price or promo publishing exists, so nothing can be scheduled or rolled back. The POS Integration Overview enumerates every add-on integration - Intraday Polling, Schedule Writeback, Till Management, and Menu Item Modifier Management (beta) - and the only outbound one is Schedule Writeback, which "sends published schedules from R365 to the connected POS" (labor shifts, not menu). It also states "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." https://docs.restaurant365.com/docs/pos-integration-overview · retrieved 2026-08-08

A new location can be provisioned by cloning a documented configuration template (menu, taxes, roles, printers, modifiers, tenders) rather than being configured from scratch, and the vendor publishes the expected time-to-open. differentiator

multi-location-new-store-template

A documented provisioning path with real copy-forward, but a checklist rather than a clone, and no published time-to-open. R365 publishes Set up a New Location, a two-part checklist that creates the location in the Setup Assistant and then works through POS integration settings, overtime rule groups, bank accounts, vendor integrations and GL mapping; for a location joining an existing concept it directs the user to "Copy an Existing Template" for inventory counts, and budgets are created with a Copy From selector naming the location to copy from. The shortfall: several steps are not self-serve at all — the checklist requires submitting an R365 Add-On Form, signing an ASR and opening a separate support ticket per vendor integration — and over the complete published corpus on 2026-09-10 the phrases `time to open`, `time-to-open`, `clone a location` and `copy a location` occur zero times. https://docs.restaurant365.com/docs/add-a-new-location · retrieved 2026-09-10

The permission model distinguishes a franchisor/corporate tenant from an independently-owned franchisee tenant, so corporate can see franchisee sales and enforce config while the franchisee owns its own employees, banking, and labor data. differentiator

multi-location-corp-vs-franchisee-roles

The docs define both roles explicitly (Franchisor = the group running R365 and billing fees; Franchisee = the billed entity), and cover franchisee/location/contract records, daily sales entry or import per franchise location, pass-through AP invoices, and multi-instance access with Channel Partners sharing Custom Financial Report templates across managed instances. https://docs.restaurant365.com/docs/franchising · retrieved 2026-08-01 adversarially verified

Calculates franchise royalty, ad-fund, and marketing-fee amounts automatically from POS net sales on a defined schedule, with a configurable royalty basis (gross vs net of discounts/comps/third-party). differentiator

multi-location-royalty-calculation

Directly documented. A Royalty Report computes a location's royalty amount for a date range, with Company Configuration setup for royalty percent and whether it calculates against Net Sales or Gross Sales, plus a legal disclaimer field and backing POS totals. This is one of the brief's flag-planted high-bar cells and it flips. https://radar.help.restaurant365.com/support/solutions/articles/12000084025-royalty-report · retrieved 2026-08-01 adversarially verified

Supports automated ACH/debit collection of calculated royalties and fees from franchisee accounts, with a franchisee-visible statement of what was charged.

multi-location-royalty-collection

The Franchising module explicitly "automates franchisee billing/ACH payment collection": fees are assigned per franchisee location, AR invoices are auto-created for a date range, and the Franchise Invoicing Report summarises invoices, credits and payments per franchisee. The collection rail is named, not inferred. https://docs.restaurant365.com/docs/franchising · retrieved 2026-08-01 adversarially verified

Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.

multi-location-consolidated-reporting

Above-store consolidation of financial and operational performance with side-by-side location comparison is the central product promise. https://www.restaurant365.com/accounting/financial-reporting/ · retrieved 2026-08-01

Item-level sales roll up across locations under a shared corporate item ID even when stores have renamed or locally priced the item. differentiator

multi-location-normalized-item-rollup

"Track item pricing across locations" and standardized recipes/order guides imply master-item mapping over differing POS item names, but the model is not documented. https://www.restaurant365.com/inventory/inventory-management/ · retrieved 2026-08-01

Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.

multi-location-cross-location-giftcard

R365 issues and redeems nothing. Its gift card documentation is entirely accounting: "Gift card sales are imported from the POS each night on their respective Sales Tickets", redemption "comes over on the sales ticket as a payment type", and both post to the Gift Card Liability GL account, reviewable via Account Detail and the Daily Flash report's Gift Cards Redeemed column. There is no card record, no per-card balance, and no redemption or inter-store settlement engine - the outstanding liability is a GL total derived from POS data. https://docs.restaurant365.com/docs/gift-cards-and-certificates · retrieved 2026-08-08

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

R365 holds no guest identity to share. The POS Integration Overview enumerates exactly what a POS import creates - Sales tickets, Menu items, Paid Outs, Deposits, POS employees, Job records, Labor details - with no customer, guest or loyalty record among them, and states "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." The Public API's 68 endpoints (Accounting, Inventory, Brand Management, Core, User Management, Sales, Labor, POS) and the Snowflake data-share view dictionary likewise contain no loyalty or guest object; the string "loyalt" appears zero times in the vendor's complete 2,366-page documentation corpus. https://docs.restaurant365.com/docs/pos-integration-overview · retrieved 2026-08-08

A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator

multi-location-multi-brand

Multi-concept/multi-entity accounting and cross-brand consolidation are supported by the entity model; there is no terminal to run two brands on. https://www.restaurant365.com/accounting/ · retrieved 2026-08-01

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

Per-entity/per-location tax accounting is inherent to the GL; POS-side tax rate configuration is out of scope.

Supports locations operating in different currencies and languages within one enterprise account, with consolidated reporting converted to a reporting currency.

multi-location-multi-currency-locale

Currency conversion exists at the transaction, not at the location. Alternate Currency Entry is "an Accounting feature that allows users to enter transactions in a different currency and convert it to the local currency for the organization." with effective-dated conversion factors and both amounts shown on the AP invoice; the worked example is a US-based organisation paying a Canadian vendor. The shortfall is threefold: the feature "is available only to Early Adopters."; it converts into one organisation-level local currency rather than letting locations operate in different currencies with a chosen reporting currency — `reporting currency` occurs 0 times across the complete 32.6M-character published corpus — and the localisation half is limited to English and Spanish. https://docs.restaurant365.com/docs/alternate-currency-entry · retrieved 2026-09-10

Produces an immutable audit log of who changed which configuration object (price, tax, permission, discount) at which location and when, exportable or queryable by corporate. differentiator

multi-location-config-audit-log

A dedicated Audit Log is documented: it records user-driven changes across master records (vendors, locations, users, employees, items), accounting (AP/AR invoices, payments, journal entries, bank transactions), operations (inventory counts, waste logs, purchase orders) and payroll, with event types "Created, Updated, Deleted, Approved, Unapproved", showing Event Date, User, Reference, Record Type, Event, Module, Location and Description; detail views show "Previous entry" and "Modified entry" columns with "Updated details ... highlighted in blue"; it is filterable by date range, user, record type, event type and location, searchable, and CSV-exportable, gated behind the Administration > Audit Log > View Audit Log permission. Named shortfalls: the documentation states nothing about immutability or retention, and the claim's named config objects (price, tax, discount) live in the third-party POS outside R365's audited record set — coverage is R365's own back-office objects, with user-permission changes covered only insofar as User records are among the audited master records. https://docs.restaurant365.com/docs/event-audit-log · retrieved 2026-08-04

Supports SSO via SAML or OIDC against the customer's identity provider for back-office/above-store users, with SCIM or equivalent for automated deprovisioning. differentiator

multi-location-enterprise-sso

Wrong site searched again. Public docs carry "Single Sign-On (SSO) Overview", "Enable Single Sign-On (SSO)" and a "Single Sign-On Wizard", documenting IdP connections to Okta and Microsoft Entra (Azure), a unique-email prerequisite check, per-instance enablement, and fallback to R365 credentials. SCIM provisioning remains undocumented — that is the only part that should stay unknown. https://docs.restaurant365.com/docs/enable-sso · retrieved 2026-08-01 adversarially verified

Publishes a documented multi-location API (or data warehouse/BI export) that returns transaction-level data across all locations in one authenticated call, without per-location credentials. differentiator

multi-location-enterprise-api

One credential covers the whole estate; one class of data still does not. Authentication is a single bearer token plus an x-r365-context-tenant-id header naming the customer instance, with no per-location credential anywhere, and /public/v1/core/locations and /public/v1/brand-management/connected-tenants-locations enumerate the estate. On the transaction-level endpoints the enumeration was tested in the direction this verdict needs, by reading the required flag on every location parameter in all 154 published operations: vendor invoices, purchase orders, item transfers, waste logs, inventory counts and labor punches all take an optional locationIds or locations filter and therefore return every location in one call, but the two sales endpoints do not. The transactions endpoint declares LocationId as "Location. Required. Only a single location is supported for v1", and /public/v1/sales/daily-sales requires both a single location and a single businessDate. The all-locations sales path is the Snowflake Secure Data Share, which is in beta for select customers. https://docs.restaurant365.com/apidocs/public-v1-accounting-transactions · retrieved 2026-09-10

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

Score stands at partial, rationale refuted. R365 does have a punch-point enforcement surface: the Time Clock Configuration screen sets job-selection prompts, schedule enforcement and break controls that act at the clock, not merely as after-the-fact alerts. It stays partial only because configuration is documented per-location with no org-level policy-inheritance object found. https://docs.restaurant365.com/docs/time-clock-configuration-details-screen · retrieved 2026-08-01 adversarially verified

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

extensibility-public-api-docs

The R365 Developer Hub renders full endpoint-level REST reference to an unauthenticated fetch (HTTP 200, no login wall, no NDA or sales-call gate). Retrieved paths include /public/v1/accounting/journal-entries, /public/v1/labor/labor-punches, /public/v1/pos/sales/import, /public/v1/items/{id}, /public/v1/purchase-orders and /public/v1/vendors/{id}, with GET, POST and PATCH operations documented per resource. The linked overview page states the Public API "covers 68 endpoints across Accounting, Inventory, Sales, Labor, and more, and supports both reading and writing data" and that "All endpoints follow the /public/v1/{domain}/{resource} pattern". Only credentials are gated -- "Contact your CSM to complete the API Credentials Request form" -- not the documentation. A legacy read-only "R365 API Connector" is marked "Legacy -- Planned for Deprecation". Withdraws the earlier note's unsupported bearer-token detail and its citation to the overview page. https://docs.restaurant365.com/apidocs/en/r365-public-apis · retrieved 2026-08-08 adversarially verified

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

extensibility-api-access-cost

API access is never published as a base-package inclusion, and where it is priced at all it sits at the top of a tier ladder. The archived price list's two core packages, Essential at "$499 / month" and Professional at "$749 / month" per location, list no API line; "API & webhook access" appears only in the $199 Premium tier of the separately sold training product. Both current API surfaces are additionally gated by admission rather than price: the Public API is a closed Early Adopter programme whose own page says "Availability and pricing are subject to change.", and the Classic API and OData connector are provisioned by R365 Support on request. Graded C because the evidence is a pricing page and specifically the archived one; the live /pricing/ page publishes no package contents at all. https://www.restaurant365.com/pricing-archive/ · retrieved 2026-09-10

The vendor publishes its partner/marketplace commercial terms (referral fee, revenue share percentage, or per-location partner fee) in public documentation.

extensibility-partner-revshare

One number is published and nothing else. The referral program page states "You can earn up to $5,000 by simply connecting potential restaurant customers with Restaurant365" and "If your referral becomes a R365 Customer, you get paid up to $5,000." Shortfall: a cap with no disclosed rate, no basis of calculation, no payout timing, and no ongoing revenue share or per-location partner fee. The partner ecosystem page (/partner-ecosystem/, successor to /partners/) publishes no commercial terms at all and routes to a contact form; the docs site's Channel Partners material is operational only. https://www.restaurant365.com/partner-referral/ · retrieved 2026-08-08

A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator

extensibility-free-sandbox

The Public API docs enumerate exactly one path to API access — "Contact your CSM to complete the API Credentials Request form" — and a CSM exists only for paying customers, so the sole documented route excludes developers without a production account. No sandbox, test environment, demo instance or trial tenant is mentioned on the Public API page, the API overview, the /apidocs Developer Hub landing, or anywhere in the full public docs index (zero hits for "sandbox" across llms.txt). Caveat: the partner program (partners@restaurant365.com) publishes no terms, so an undocumented partner sandbox cannot be ruled out — but nothing published offers one, and the claim requires availability without a paid account. https://docs.restaurant365.com/docs/r365-public-api · retrieved 2026-08-04

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

Both published API surfaces authenticate with long-lived shared secrets and neither offers an operator-granted scoped grant. The Public API authentication article, updated 2026-09-08, states that "Every request to the Restaurant365 Public API carries two pieces of information: who you are, and which customer instance you are acting on." and its required-headers table names exactly two: an Authorization bearer token that "Acts as your API key." and is delivered once through a 1Password share link, and x-r365-context-tenant-id. Revocation is a support call — "Contact Restaurant365 Support to rotate a token". The Classic API exchanges a UserName and Password for a JWT. The securitySchemes block extracted from all 186 published OpenAPI reference pages declares one scheme, an HTTP bearer with bearerFormat JWT. OAuth does appear in the documentation three times, but only as OIDC single sign-on for human logins via Okta; `OAuth 2.0` and `refresh token` occur 0 times across the whole 32.6M-character corpus. https://docs.restaurant365.com/apidocs/authentication · retrieved 2026-09-10

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

extensibility-webhooks-push

The API overview enumerates R365's integration surfaces exhaustively — three, and every one is pull: the R365 Public API (REST, /public/v1/{domain}/{resource}, ~68 endpoints across eight domains, reads and writes, the recommended surface); Secure Data Share (read-only Snowflake, positioned for bulk/analytical queries as an alternative to "individual API requests"); and the legacy R365 API Connector (read-only REST, marked for deprecation). No webhook, event-subscription, callback or push-notification surface appears on the API overview, the Public API page or the /apidocs Developer Hub landing page. Independently, the claim's subject cannot exist here: order lifecycle events (created, modified, paid, voided, refunded) originate in the POS, and R365 ingests POS sales data rather than producing orders — the record already scores extensibility-order-injection-api as no for the same reason. The status page's incident webhooks are ops alerting, not a data event stream. Caveat on strength: per-endpoint reference schemas sit behind CSM-issued credentials and were not readable, so this rests on the surface enumeration rather than an exhaustive endpoint listing. https://docs.restaurant365.com/docs/r365-api · retrieved 2026-08-04

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

Absent because the surface itself is: the API overview enumerates all three integration methods — the R365 Public API (versioned REST pull, /public/v1/{domain}/{resource}), Secure Data Share (read-only Snowflake access "instead of making API requests"), and the legacy R365 API Connector (read-only REST, deprecating) — and none is push or event-driven, so there is no webhook to be signed, retried or replayed. Mirrors extensibility-webhooks-push, scored no on the same enumeration. The status page's incident webhooks are ops alerting, not a data event stream, and carry no documented signing/retry/replay contract either. https://docs.restaurant365.com/docs/r365-api · retrieved 2026-08-04

A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.

extensibility-order-injection-api

The R365 Public API is real and supports writes - "68 endpoints across Accounting, Inventory, Brand Management, Core, User Management, Sales, Labor, and POS" on a /public/v1/{domain}/{resource} convention - but its POS domain is inbound only: /pos/sales/import, /pos/paidouts/import, /pos/tills/import, /pos/deposits/import, /pos/labor/{punches,employees,job-titles}/import, /pos/imports/{importId} and /pos/trigger. Those load already-closed POS activity into R365's ledger; there is no order, ticket, check or fire endpoint, R365 documents no KDS or printer routing at all, and "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." Credentials also require a CSM-submitted request form. https://docs.restaurant365.com/docs/r365-public-api · retrieved 2026-08-08

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

extensibility-menu-write-api

Read-only for every item, recipe and price object, and the enumeration is closed on both surfaces. Extracting the embedded OpenAPI fragment from each of the 186 published R365 Developer Hub pages yields 154 operations — 114 GET, 30 POST, 10 PATCH. Every write is on the accounting or administrative side: AP invoices, AP credit memos, AP payments, journal entries, GL accounts, users, smart-safe deposits, and the POS import endpoints that push sales, tills, paid-outs, punches, employees and job titles into R365. Items, item categories, vendor items, units of measure and recipes are GET-only, in both the /public/v1/inventory/{resource} and the older /public/v1/{resource} spelling. The other direction is closed by the vendor's own warning on the alternative surface: "The R365 Classic API is a REST API. It is read-only." https://docs.restaurant365.com/apidocs/public-v1-inventory-items · retrieved 2026-09-10

Every core object the API can read (orders, menu, customers, employees, inventory) can also be written or updated via the same API. differentiator

extensibility-data-symmetry

Should move up to at least partial: the Public API is documented as supporting both reads and writes across Accounting/Inventory/Sales/Labor and a POST example (/APIv1/JournalEntries) is published. Per-object write coverage is not enumerated publicly, so partial is the defensible landing spot, not full yes. https://docs.restaurant365.com/docs/r365-api-connector · retrieved 2026-08-01 adversarially verified

API rate limits are published as specific numeric quotas with documented throttling behavior and headers.

extensibility-published-rate-limits

The behaviour is documented; the number is not, and neither are the headers. The published status-code table names 429 and tells the caller what to do — the row reads "The request rate limit for the customer instance was exceeded." against "Slow the request rate and retry with progressive backoff rather than retrying immediately." — but states no quota. Tokenised over the complete published corpus on 2026-09-10 (32.6M characters): `rate limits` 0, `throttling` 0, `X-RateLimit` 0, `Retry-After` 0, `requests per minute` 0, `requests per second` 0, and `rate limit` exactly once, in that table row. The only published numbers are a page size — "Set pageSize to control the number of results per page. The maximum is 250." — and a filter width, "You can retrieve up to 31 days (one month) of sales data per request.", neither of which is a rate. https://docs.restaurant365.com/apidocs/public-api-troubleshooting-status-codes-errors · retrieved 2026-09-10

The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator

extensibility-doordash-preferred

DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a count of how many of the eight high-quality features the provider has built. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is what the program page means when it says the roster is tracked in real time, and it is a CENSUS rather than a floor: every provider integrated with DoorDash appears in it with a tier, so a vendor that is absent altogether is not in the programme at any tier. This vendor appears nowhere in the 64 entries, under any provider id or friendly name — checked mechanically against both fields, with the only near-misses being substring coincidences (Speedline against Lightspeed, vroom_restaurant against Restaurant365) that were read and rejected. SUPERSEDES the 2026 announcement post most of this corpus cited: that post introduces its ten names with the word `include`, which makes it a floor and never a ceiling, and reading it as a ceiling is what produced this cell's prior grade. GRADE HARMONISED TO B, 2026-09-11: this URL was first written at grade A. The adversarial pass ruled E on the principle that the rubric grades by the publisher's relationship to the SCORED vendor, and DoorDash is not that vendor. B is the settlement, for two reasons that are not preference: 39 rows already graded a DoorDash-published document B on this claim before today, and one URL on one claim cannot carry two grades; and E is unworkable, because nine of the 47 rows are `yes` on a differentiator-weight claim, which the grade floor refuses below B. B reads as the product documentation of the programme's own publisher, which is what this registry is. The dissent is recorded in verification.jsonl. https://merchants.doordash.com/api/partner-integrations · retrieved 2026-09-11

Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator

extensibility-first-party-delivery-integrations

Delivery platforms appear in the partner ecosystem as data sources for sales/fees; no certified order-injection integrations. https://www.restaurant365.com/partner-ecosystem/ · retrieved 2026-08-01

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

extensibility-middleware-compatibility

No aggregation middleware treats R365 as an endpoint, and R365 documents none. Tokenised over the complete published corpus on 2026-09-10 (5,592 files, 32.6M characters): `Deliverect` 0, `Otter` 0, `Checkmate` 0, `Cuboh` 0, `Ordermark` 0; `Chowly` 1 and `ItsaCheckmate` 5, every one of them inside marketing blog posts surveying the delivery-integration market rather than describing an R365 integration, and none inside the 2,629-page product documentation. The structural reason is in scope: R365 receives closed sales from whichever POS the operator already runs and has no order-injection surface for middleware to write to, which is why this record's peer-group scope already excludes order-capture, digital-ordering and delivery. https://docs.restaurant365.com/llms.txt · retrieved 2026-09-10

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

R365 replaces the GL rather than connecting to one; it publishes migration/comparison paths from QuickBooks, NetSuite and Sage Intacct. https://www.restaurant365.com/restaurant365-vs-quickbooks/ · retrieved 2026-08-01

Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.

extensibility-payroll-export

Same evidence: ADP, Paychex, Paycom and APS named in public documentation, plus CSV tip-distribution export. https://docs.restaurant365.com/llms.txt · retrieved 2026-08-01 adversarially verified

Raw transaction-level data can be exported on a schedule to a customer-controlled destination (S3/SFTP/warehouse/Snowflake share), not only viewed in the vendor's reporting UI. differentiator

extensibility-bi-data-warehouse

An OData connector for Excel and Power BI with documented data endpoints is listed in the public docs index, alongside the Snowflake Secure Data Share. This is affirmatively documented BI/warehouse connectivity, not an inference. https://docs.restaurant365.com/llms.txt · retrieved 2026-08-01 adversarially verified

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

extensibility-app-marketplace

Public browsable partner directory of 500+ partners across 24 categories with tiering (Bronze–Platinum); self-install is not offered. https://www.restaurant365.com/partner-ecosystem/ · retrieved 2026-08-01

Operators can define custom fields or run vendor-hosted custom logic/scripts against POS objects without a vendor engineering engagement.

extensibility-custom-fields-scripting

Self-serve custom fields are documented: an admin Custom Fields page where fields and their values are user-created ("Options are user-created values that comprise the selection choices for the custom field") and assigned to transaction record types — no vendor engineering engagement in the workflow. Named shortfalls: scope is narrow — custom fields attach only to AP invoices, AP credit memos and journal entries, with a maximum of 3 active custom fields per transaction type, and values are picklist options; no custom fields on any other object (items, employees, vendors, locations), and no scripting, formula or vendor-hosted custom-logic surface is documented anywhere in the docs corpus. https://docs.restaurant365.com/docs/custom-fields · retrieved 2026-08-04

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

No headless mode is possible because no transaction resource is exposed. The Public API's 68 endpoints span Accounting, Inventory, Brand Management, Core, User Management, Sales and POS-import; the Sales domain is /public/v1/sales/daily-sales (reporting) and the POS domain is import-only. Nothing creates or advances an order, tender or check, and R365 documents no kiosk, drive-thru or web-ordering product. Access is gated as well - "Contact your CSM to complete the API Credentials Request form" - so there is not even a self-serve surface to embed against. https://docs.restaurant365.com/docs/r365-public-api · retrieved 2026-08-08

The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.

extensibility-api-versioning-deprecation

Should move up to at least partial: docs publish an explicit versioned namespace (/public/v1/) and a stated deprecation path — the legacy API Connector is documented as read-only and planned for deprecation with new integrations directed to the Public API. No dated changelog or deprecation-window commitment found, so do not score this above partial. https://docs.restaurant365.com/docs/r365-api · retrieved 2026-08-01 adversarially verified

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

Machine-readable export mechanisms are documented and the right to use them is affirmed — but only up to the moment of termination, and the completeness of the export is nowhere stated. The current master subscription agreement, v9.1 last updated May 15 2025, says "The Customer will be responsible for exporting data out of the System prior to the effective date of termination." and R365 publishes several documented machine-readable routes to do it: an OData connector usable from Microsoft Excel, PowerBI, Domo, Prophix or "Any reporting provider that accepts OData", the read-only Classic REST API, and the beta Snowflake Secure Data Share with its 20-view published data dictionary. The shortfall is real and is the reason this is not a yes: no document defines a complete historical export as a deliverable, no format or scope is guaranteed at contract end, and the same MSA sentence continues "Restaurant365 shall delete all of the Customer's information, with the exception of any Aggregated Data, from the System the day after the effective date of termination." https://www.restaurant365.com/wp-content/uploads/2025/05/R365-MSA_5.25-v9.1.pdf · retrieved 2026-09-10

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

reliability-offline-order-entry

R365 is a browser-delivered cloud application: "By design, Restaurant365 is accessible from any internet connected device via a web browser" and "Restaurant365 is cloud-based, and as such, does not require local storage to use the application." There is no order-entry surface to keep running: "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." and sales reach R365 as Sales Ticket records polled after the POS close of day. The only on-premise software R365 documents is the "local install" connector - "a lightweight R365 application polls data from a POS computer or back-office server" - which collects data and does not capture orders. https://docs.restaurant365.com/docs/restaurant365-system-requirements · retrieved 2026-08-08

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

reliability-offline-card-auth

R365 accepts no card payments, so store-and-forward does not arise. The R365 Payments Service Overview describes an outbound accounts-payable product: it "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)", US bank accounts only. Guest card payments appear in R365 only as imported POS payment types on a Sales Ticket, and the legacy Catering module records customer payments as manually keyed AR receipts. https://docs.restaurant365.com/docs/r365-payments-service · retrieved 2026-08-08

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

Nothing to document: R365 runs no card authorization, so there is no offline decline, no liability allocation and no offline cap to publish. The only payments product, R365 Payments, is outbound AP - "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)" - and guest card tenders enter R365 only as POS-imported payment types posted to the GL. https://docs.restaurant365.com/docs/r365-payments-service · retrieved 2026-08-08

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

R365 is a browser-delivered cloud application: "By design, Restaurant365 is accessible from any internet connected device via a web browser" and "Restaurant365 is cloud-based, and as such, does not require local storage to use the application." There are no terminals and no check or table state in R365 to share over a LAN - checks are closed in the connected POS and imported afterwards as Sales Tickets. The only local component is the "local install" polling application on a POS or back-office computer, and the documented behaviour when it loses connectivity is simply a missed import: "ensure that the back office computer is running and has an active internet connection. Once reconnected, the missing DSS will automatically repoll." https://docs.restaurant365.com/docs/restaurant365-system-requirements · retrieved 2026-08-08

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

R365 does document an on-premise component, but it is not a transaction engine: under Polling and Connection Methods the "local install" option is "a lightweight R365 application polls data from a POS computer or back-office server", alongside cloud (API) and FTP connections, and its job is retrieving POS data on a schedule. The application itself is cloud-hosted and browser-delivered - "Restaurant365 is cloud-based, and as such, does not require local storage to use the application" - and there is no ordering path for an edge server to serve. https://docs.restaurant365.com/docs/pos-integration-overview · retrieved 2026-08-08

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

reliability-offline-kds-printing

R365 has no kitchen display or kitchen printer routing to keep running, online or offline. "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." and the documented data flow is a scheduled poll after the POS close of day producing a Daily Sales Summary. The strings "KDS", "kitchen display" and "kitchen printer" occur zero times in the vendor's complete 2,366-page documentation corpus indexed by docs.restaurant365.com/llms.txt; the only printing R365 documents is report and recipe printing. https://docs.restaurant365.com/docs/pos-integration-overview · retrieved 2026-08-08

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

There is no kitchen printer or KDS station in R365 to fail over between. Ticket routing happens in the connected POS - "The POS remains the source of record for daily sales and labor activity. R365 reports on this data but does not modify the information stored in the POS." - and R365 ingests the result nightly as a Daily Sales Summary. No printer configuration, routing rule, station or kitchen alerting surface exists in the 2,366-page corpus; R365's printing features are report and recipe printing. https://docs.restaurant365.com/docs/pos-integration-overview · retrieved 2026-08-08

The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).

reliability-sync-conflict-handling

The two-device case is addressed for punches and disclaimed rather than resolved; for concurrent inventory counting the behaviour is asserted but the conflict rule is not. R365 documents that the punch log is per-device — "The Punch Action Log is device-specific. Each Timeclock tablet stores its own log. Punches made on a different device at the same location are not visible in this device's log." — and gives a manual reconciliation path for punches that did not land, with Failed and Blocked statuses and a resync that on a Blocked punch "works like a manager override after the fact". For inventory counts, "Multiple users can participate at the same time, and progress updates in real time as entries are made." and "Counts recorded while offline are stored locally and sync automatically when the device reconnects." The shortfall: no document states what happens when two devices submit a different value for the same count line. Tokenised over the complete 32.6M-character published corpus, `last-write` occurs 0 times, and every conflict hit is a schedule rule violation, a duplicate user record, or an HTTP 409 on a duplicate email. https://docs.restaurant365.com/docs/resync-failed-or-blocked-punches · retrieved 2026-09-10

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

FAQ states only that "some app features" work offline, citing inventory counts; no explicit matrix published. https://www.restaurant365.com/faqs/ · retrieved 2026-08-01

A public, per-component status page exists showing current and historical incident state without a login.

reliability-public-status-page

25+ components (Customer Databases, R365 Payroll, POS integrations, FTP File Watcher, API, AI Dashboards, Radar, Accounting 2.0, Inventory 2.0), incident history, and published 90-day uptime percentages (e.g. Website 99.98%). https://status.restaurant365.com/ · retrieved 2026-08-01

A contractual uptime SLA with a stated percentage AND a service credit remedy is published or available in the standard agreement. differentiator

reliability-contractual-uptime-sla

A stated percentage exists, in one agreement and for one product, and no service credit accompanies it. The R365 Payroll Service Agreement publishes Service Level Objectives in which "The service level objective for Systems availability is ninety nine and" "nine tenths (99.9%) percent of the time measured over three (3) consecutive months." with named exclusions, plus twice-weekly maintenance windows and two weeks' notice of scheduled maintenance. The shortfalls are both halves of the rest of the claim. First, that agreement covers R365 Payroll, provided "in partnership with" Automatic Payroll Systems, Inc., not the back-office platform: the current Master Subscription Agreement, v9.1 of May 15 2025, contains the tokens `uptime`, `SLA` and `Service Level Agreement` zero times. Second, no service credit is attached to the 99.9% objective; the only service-credit remedy R365 publishes, capped at ten percent of fees, is in the legacy Compeat Services Agreement for the acquired Compeat product. https://www.restaurant365.com/wp-content/uploads/2024/06/R365-APS-Payroll-Service-Agreement.pdf · retrieved 2026-09-10

The vendor publishes written post-incident reports or root-cause summaries for major outages.

reliability-incident-postmortems

R365 published a full formal root-cause document on its public status page for the March 2025 Daily Sales Summary incident, headed Postmortem and "Root Cause Analysis (RCA)", with an Incident Overview, a minute-by-minute four-day Timeline, Scope, a Root Cause section separating cause identification from technical explanation — "The root cause was determined to be the Comida" Director's "limited parallelism" and it "was processing only 10 locations at a time" — Contributing Factors, an Impact Analysis giving reported case counts by day and a "Severity 1" rating, Corrective Actions, Preventative Measures, and a "Document Approval" block naming the preparer, reviewer and approver by name and date. Bounded honestly: every published incident was enumerated from the status page's own history (132 incidents over 72 months, October 2020 to September 2026) and every incident page fetched; 3 of the 132 carry a postmortem section and only this one is a full RCA document. Note that the Statuspage JSON API is the narrower instrument here — its incident_updates array does not carry the postmortem body, so a reader working only from /api/v2/incidents.json would conclude, wrongly, that none exists. https://status.restaurant365.com/incidents/crcthr4c5ytr · retrieved 2026-09-10

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

Support Center states chat availability 8am–5pm CT, Monday–Friday; no included 24/7 phone line advertised. https://help.restaurant365.net/support/home · retrieved 2026-08-01

The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator

reliability-onsite-install

The documented go-live model is remote and guided, with no first-party or dealer on-site option anywhere. R365 publishes an onboarding sequence in which the customer completes a self-serve Onboarding Dashboard and then continues "through implementation with guidance from an R365 Implementation Specialist." — a process whose contact model is "scheduled calls with the Implementation Specialist and access to self-serve resources". Tokenised over the complete 32.6M-character published corpus on 2026-09-10, the only Onsite Visits heading belongs to an R&D usability-research programme, and the only on-site party in a deployment procedure is the customer's own, in a step reading "R365 Support" and "an" "on-site user" "complete the integration." This is structurally consistent with the product: R365 sells no terminals and installs no hardware. https://docs.restaurant365.com/docs/r365-onboarding · retrieved 2026-09-10

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

reliability-menu-build-service

SHORTFALL: separately priced, delegable to a third party, and the data entry is contractually the operator's. MSA v9.0 §13: "Setup of the System on behalf of Customer shall be performed by R365 or a third party who selected by Customer from a group of approved providers (the 'Designated Service Partner')." §13.a: R365-performed setup carries a setup fee on a signed Additional Service Request, minimum the "'Standard' Implementation service fee ... based on activities that are defined in the R365 Scope of Work Document." §13.b: where a DSP does it, the customer contracts and pays the DSP directly and "R365 shall not have any liability or responsibility ... in connection with the setup of the System." §15.a: if the customer does not deliver its documents and desired configurations on schedule, "the Customer will be charged additional setup and configuration fees." The onboarding docs are correspondingly customer-led — "User can create new Purchased Items, Vendor Items", "User understands ... mapping a Recipe to a Menu Item", "Coach has provided Menu Item Category worksheet to User." https://www.restaurant365.com/wp-content/uploads/2024/06/R365-MSA-11.2024.pdf · retrieved 2026-08-02 adversarially verified

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

reliability-hardware-replacement-sla

R365 sells no hardware, so there is no replacement or advance-exchange program. Devices are customer-owned and customer-managed: "Enterprise administrators can deploy and manage the R365 mobile app on both phones and tablets using their existing mobile device management (MDM) tools", via Apple Business Manager or managed Google Play, and R365 Time Clock runs as a provisioned session on the customer's iPad or Android tablet. System Requirements specify customer Windows/Mac browser machines. Hardware failure is handled by re-provisioning a replacement device, not by a vendor SLA. https://docs.restaurant365.com/docs/r365-app-mobile-device-management-mdm · retrieved 2026-08-08

Operators can trigger and retrieve their own data backup/restore, or the vendor publishes RPO/RTO figures for data recovery.

reliability-backup-restore

RPO and RTO figures are published, for one product only, and no operator-triggered restore exists. The R365 Payroll Service Agreement states a Recovery Point Objective — "The service level objective of the data replication" "and backup systems is to provide a recovery point of no more than fifteen (15) minutes." — and a Restore Time Objective — "The service level objective of the continuity plan is to" "provide a restore point of no more than three (3) hours." Both shortfalls matter. That agreement governs R365 Payroll, delivered in partnership with Automatic Payroll Systems, Inc., and the tokens `RPO`, `RTO` and `disaster recovery` appear zero times in the current Master Subscription Agreement covering the back-office platform. And nothing in the 2,629-page product documentation gives an operator a self-service backup or restore: `self-service backup` occurs 0 times, and every restore hit is un-archiving a single record such as a menu item or a dashboard widget. https://www.restaurant365.com/wp-content/uploads/2024/06/R365-APS-Payroll-Service-Agreement.pdf · retrieved 2026-09-10

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

No attestation of any kind is published. Tokenised over the complete published corpus assembled 2026-09-10 — 5,592 files, 32.6M characters — `Attestation of Compliance` occurs 0 times, `P2PE` 0, `SAQ` 0, and `PCI DSS` exactly once, inside an R365 blog post explaining the standard to restaurant readers. A Vanta-hosted trust centre does exist at trust.restaurant365.com, which is why this is a statement about what is published rather than about what R365 holds: that host answers every path including /robots.txt and a fabricated filename with one 5.4KB React shell carrying 17 characters of text, its data comes from app.vanta.com, which bars all crawlers host-wide, and every Wayback capture of it back to May 2024 is the same shell. Its contents were therefore not read and are not claimed either way. https://docs.restaurant365.com/llms.txt · retrieved 2026-09-10

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

reliability-mfa-role-based-access

Should move up to at least partial: the RBAC half is fully documented (permission tree, custom user roles, report roles, location scoping) and SSO to Okta/Entra is documented, which is the standard MFA delegation path. Native MFA enforcement for non-SSO credential logins is still undocumented, so partial rather than full yes. https://docs.restaurant365.com/docs/user-setup-security-and-location-access · retrieved 2026-08-01 adversarially verified

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

reliability-self-serve-training

Public login-free Knowledge Base and community forum exist; a free public video/LMS library and practice environment are not documented (ExpandShare training is a paid product for the operator's own staff). https://help.restaurant365.net/support/home · retrieved 2026-08-01

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

reliability-failover-terminal-role

R365 is a browser-delivered cloud application: "By design, Restaurant365 is accessible from any internet connected device via a web browser" and "Restaurant365 is cloud-based, and as such, does not require local storage to use the application." There is no master or server terminal role to fail over: sessions are independent browser or mobile-app clients against the hosted instance, and the only on-premise component is the "local install" poller that "polls data from a POS computer or back-office server" for the scheduled import. Terminal roles, where they exist, belong to the connected POS. https://docs.restaurant365.com/docs/restaurant365-system-requirements · retrieved 2026-08-08

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

reliability-cellular-backup

R365 supplies neither terminals nor connectivity, so no cellular/LTE failover is documented. The MDM article's only network prerequisite is that "the selected devices can reach your R365 instance URL", and System Requirements ask for "ADSL or Broadband for home/business and 3G internet speeds or greater for mobile devices" - a recommendation about the customer's own connection, not a vendor-provided failover path. No LTE, cellular backup or dual-WAN feature appears in the corpus. https://docs.restaurant365.com/docs/r365-app-mobile-device-management-mdm · retrieved 2026-08-08

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

The published standard agreement forbids it in terms. Master Subscription Agreement v9.1, last updated May 15 2025, section 4: the initial period runs for the term on the order form and is "subject to successive automatic annual renewal or multi-year renewal, as specified on the Order Form" and continues unless "either party provides written notice" "to the other party of its intent not to renew the Agreement at least sixty (60) days prior to the end of the Initial Period". Section 5 opens "This Agreement may not be terminated or cancelled, nor may Services be downgraded by the Customer" "prior to the end of the Initial Term or an applicable Renewal Period." and section 6 adds that "Subscriptions are not cancellable or downgradable and Customer will be held responsible for full" "payment of the entire Subscription term." The single carve-out is location closure on 60 days' notice with documentary evidence. R365's archived price list is quoted per location per month but "billed quarterly". This corrects the prior note: the MSA PDFs extract to text cleanly — 46,440 characters for this one. https://www.restaurant365.com/wp-content/uploads/2025/05/R365-MSA_5.25-v9.1.pdf · retrieved 2026-09-10

Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator

commercial-no-early-termination-fee

The published MSA (v9.0, Nov 2024) states the opposite of this claim. §5 Termination: "This Agreement may not be terminated or cancelled, nor may Services be downgraded by the Customer prior to the end of the Initial Term or an applicable Renewal Period." §6 Subscription: "Subscriptions are not cancellable or downgradable and Customer will be held responsible for full payment of the entire Subscription term." §10 Refunds: no refunds for "non-usage, cancellations, downgrades or location closures" unless legally required. There is no fixed ETF only because early exit is contractually barred outright — the customer owes the full remaining term, which is stricter than a termination fee. §4 auto-renews annually (or multi-year per Order Form) absent 60 days' written notice to renewals@restaurant365.com. https://www.restaurant365.com/wp-content/uploads/2024/06/R365-MSA-11.2024.pdf · retrieved 2026-08-04

The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.

commercial-autorenew-terms-published

A public versioned MSA archive back to August 2018 (current Nov 2024 v9.0) plus addendums is posted, but renewal/notice terms could not be read from the linked documents. https://www.restaurant365.com/master-agreements-and-addendums/ · 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

R365 sells no card acquiring and imposes no processor requirement; it integrates with whatever POS/processor the operator runs. https://www.restaurant365.com/partner-category/pos/ · retrieved 2026-08-01

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

commercial-interchange-plus-published

R365 does no card acquiring, so no interchange-plus (or blended) merchant rate is published. Its similarly named product runs the other way: R365 Payments "delivers payments to each of your vendors using the best available payment method, whether that be check, ACH, virtual credit card (vCard)", for organizations with US bank accounts. Merchant processing belongs to whichever POS and processor the operator runs; R365 only imports the resulting payment-type totals to the GL. https://docs.restaurant365.com/docs/r365-payments-service · retrieved 2026-08-08

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

MSA v9.0 (Nov 2024) §8 Fees Generally: "During each 12-month period from the date of execution of this Agreement, R365 shall have the right in [sic] increase the price for any component or integration that the Customer is subscribed for; provided, that such price may not increase by more than 8% in any 12-month period." An explicit contractual cap on unilateral vendor-initiated increases. Caveat: the cap governs subscription fees — R365 sells no card acquiring, so there is no processing rate to cap. No penalty-free exit on increase; §4 requires 60 days' written notice of non-renewal to renewals@restaurant365.com or the agreement auto-renews. https://www.restaurant365.com/wp-content/uploads/2024/06/R365-MSA-11.2024.pdf · 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

Pricing page is quote-only; the plan comparison matrix is published only as an image asset. https://www.restaurant365.com/pricing/ · retrieved 2026-08-01

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

commercial-module-unbundling

Essential/Professional packages plus standalone modules (Inventory, Scheduling, Hire) are offered; independent cancellation without repricing is not documented. https://www.restaurant365.com/plan-comparisons/ · retrieved 2026-08-01

All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.

commercial-hardware-purchase-outright

R365 sells no terminals, KDS screens or printers, so nothing can be purchased outright from it - and equally nothing is leased. Deployment is on hardware the operator already owns: "Enterprise administrators can deploy and manage the R365 mobile app on both phones and tablets using their existing mobile device management (MDM) tools" (Apple Business Manager or managed Google Play), with the browser application running on customer Windows/Mac machines per System Requirements. No hardware catalogue or price list exists on the vendor site or in the docs. https://docs.restaurant365.com/docs/r365-app-mobile-device-management-mdm · 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

Not applicable: browser back office plus an app on the operator's own iOS/Android devices; no vendor hardware exists. https://www.restaurant365.com/faqs/ · retrieved 2026-08-01

One-time implementation, menu-build, onboarding, and training fees are published as specific amounts or explicitly stated as $0.

commercial-implementation-fee-published

Not published; reviewers report substantial paid professional services. https://www.restaurant365.com/pricing/ · retrieved 2026-08-01

Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.

commercial-data-export-self-serve

Ad-hoc reporting and automated distribution imply export, but a documented full-history self-serve transactional export is not published. https://status.restaurant365.com/ · retrieved 2026-08-01

Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator

commercial-export-customer-and-loyalty

There is no guest, loyalty or card-level ledger in R365 to export. The Public API's published endpoint index (68 endpoints across Accounting, Inventory, Brand Management, Core, User Management, Sales, Labor, POS) contains no customer, guest, loyalty or gift-card resource, and the Snowflake Secure Data Share view dictionary enumerates its views - Legal Entity, Location, User, User Access, Budget, Calendar, GL Account Activity, Sales, Product Mix, Payments, Menu Items, Inventory Activity, Inventory Item, Menu Item Map, Vendor, Employee, Labor Activity - again with no guest or loyalty view. Gift cards exist only as a Gift Card Liability GL balance imported from the POS, so the exportable guest-side data is an accounting total, not customer records or a points ledger. https://docs.restaurant365.com/docs/r365-public-api · retrieved 2026-08-08

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

The published agreement specifies the opposite of a retrieval window. Master Subscription Agreement v9.1, section 5: "Upon any termination hereunder, all rights to use the System and any services contemplated hereunder terminate" "immediately. The Customer will be responsible for exporting data out of the System prior to the effective date of" "termination. Restaurant365 shall delete all of the Customer's information, with the exception of any Aggregated Data," "from the System the day after the effective date of termination." That is an affirmative one-day cutoff placing the export burden entirely before termination, not an unstated term — which is what moves this cell off unknown. https://www.restaurant365.com/wp-content/uploads/2025/05/R365-MSA_5.25-v9.1.pdf · retrieved 2026-09-10

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

ToS states "you are the owner of all rights, title and interest in and to the User Data" but grants R365 a "non-exclusive, perpetual, royalty-free, fully paid up, worldwide license to use your User Data" with no aggregation/de-identification limit. https://www.restaurant365.com/terms/ · retrieved 2026-08-01

The POS is source-available or open source with a documented self-hosting option (source published under an OSI or source-available license, not merely an open API).

commercial-source-available-selfhost

Restaurant365's terms grant only "a non-exclusive, nontransferable, revocable and limited right and license to access and use the Website through a web browser" and state that "You agree not to engage in any reverse engineering, de-compiling or other activities designed to view the source code", with all components "including without limitation any computer code" owned by the vendor. No source is published under any licence and no self-hosted deployment option is offered; System Requirements confirm the product is cloud-hosted and browser-delivered. https://www.restaurant365.com/terms/ · retrieved 2026-08-08

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

R365 documents no card-entry surface and names no SAQ. Tokenised over the complete published corpus on 2026-09-10 (5,592 files, 32.6M characters): `P2PE` 0 hits, `SAQ` 0, `cardholder data` 1 and `tokenization` 1, both of the latter in the same R365 blog post advising restaurant readers about their POS rather than describing R365. The money R365 does move is outbound — R365 Payments disburses accounts-payable to vendors over ACH and printed cheques, governed by a published ACH scope of work — and no part of the platform accepts a guest card, so there is no merchant PCI scope for R365 to reduce and no SAQ for it to name. https://docs.restaurant365.com/llms.txt · retrieved 2026-09-10

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

The MFA half is real and documented; the PCI framing and the script-integrity half are absent. R365 documents multi-factor authentication as a configurable platform control — allowed MFA methods are set at the organisation level and shared across instances, "User Roles that are shared across Instances will share MFA requirement settings", and enrolment and frequency follow the user across instances — and MFA has its own status-page component with a recorded 2026-05-28 incident. Two shortfalls. First, it is not universal: "MFA is only available as part of the R365 Professional Package", so an Essential-tier customer cannot enforce it at all. Second, R365 never connects any of this to PCI DSS v4.0.1 — across the complete 32.6M-character published corpus `script integrity` occurs 0 times, requirements 6.4.3 and 11.6.1 are never cited, and R365 hosts no payment page to monitor. https://docs.restaurant365.com/docs/mfa-across-instances · retrieved 2026-09-10

Vendor states it holds a current SOC 2 Type II (or ISO 27001) attestation and will provide the report under NDA via a trust center or on request.

commercial-soc2-attestation

A contractual commitment to a SOC-standard audit and to producing the report on request exists; a named current SOC 2 Type II does not. The R365 Payroll Service Agreement, section 4.3 Audits: "R365 will have, at a minimum, an annual audit of its General Controls including, but not" "limited to, information security controls, performed by a third-party audit firm based on the Service" "Organization Controls" audit standard report or equivalent, and "Upon request, R365 will make" "available to Client for review annually, its SOC audit report or equivalent." with the report treated as Confidential Information and control exceptions carrying management responses. The shortfalls: the commitment says SOC or equivalent rather than SOC 2 Type II and appears in the Payroll agreement rather than the platform MSA; and across the complete 32.6M-character published corpus the strings `SOC 2`, `SOC 1` and `ISO 27001` occur exactly once each, all three in the same R365 blog post and all three describing NetSuite, not Restaurant365. A Vanta trust centre exists at trust.restaurant365.com but serves one React shell for every path and its data host app.vanta.com bars all crawlers, so it was not read. https://www.restaurant365.com/wp-content/uploads/2024/06/R365-APS-Payroll-Service-Agreement.pdf · retrieved 2026-09-10 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

Deletion requests handled by emailing legal@restaurant365.com with a stated subject line; no in-app DSAR tooling and no published DPA found. https://www.restaurant365.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

Accessibility statement describes practices (keyboard nav, alt text, contrast) but makes no WCAG conformance claim and offers no VPAT/ACR. https://www.restaurant365.com/accessibility-statement/ · retrieved 2026-08-01

POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator

commercial-dual-pricing-compliant

R365 cannot apply a surcharge or cash discount because it does not take the payment; its payments product is outbound AP vendor disbursement by "check, ACH, virtual credit card (vCard)". Surcharging appears in R365 only as POS import configuration for charges the POS has already applied: the Aloha integration offers "Accept surcharge and order mode charge - allows Service Charge and Order Mode Charge to be imported", and the Square integration offers "Card surcharge as sales item - routes card surcharge service charges as positive sales detail items". Debit/prepaid exclusion and receipt or menu-board disclosure are functions of the POS and processor, not R365. https://docs.restaurant365.com/docs/r365-payments-service · retrieved 2026-08-08