Restaurant365

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

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

menu-pricing-fractional-placement differentiator

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

menu-pricing-half-and-half-rule differentiator

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

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

menu-pricing-size-style-matrix differentiator

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

menu-pricing-included-allowance differentiator

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

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

menu-pricing-upsell-prompts differentiator

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

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

menu-pricing-countdown-auto-86 differentiator

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

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

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

menu-pricing-dual-pricing differentiator

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-pricing-versioning-effective-dates differentiator

No public documentation of staged publish, preview, or rollback for item/recipe records.

menu-pricing-franchise-hierarchy differentiator

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

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-pricing-recipe-linkage differentiator

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

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

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

payments-processor-choice differentiator

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

payments-published-rates differentiator

No card acquiring product, so no card rates exist. https://www.restaurant365.com/r365-payments/ · retrieved 2026-08-01

payments-dual-pricing differentiator

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

payments-surcharge-guardrails differentiator

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

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

payments-softpos-tap-to-pay differentiator

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

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

payments-qr-guest-pay differentiator

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

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

payments-tip-pooling differentiator

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

payments-offline-store-and-forward differentiator

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

payments-offline-decline-liability differentiator

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

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

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

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

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

payments-chargeback-tooling differentiator

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

payments-card-on-file differentiator

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

payments-payout-timing differentiator

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

payments-multi-entity-routing differentiator

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

payments-p2pe-pci4

No public PCI AoC or P2PE listing located; no vendor trust/security page found.

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

labor-photo-punch-verification differentiator

Not documented on public pages.

labor-geofenced-mobile-punch

Mobile timecard visibility/corrections are documented; geofenced punching is not.

labor-offline-time-punch differentiator

FAQ documents offline mobile inventory counts only; offline punching is not addressed.

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

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

labor-native-scheduling differentiator

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

labor-demand-labor-forecast differentiator

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

labor-realtime-labor-percent differentiator

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

labor-overtime-prevention differentiator

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

labor-break-compliance-by-state differentiator

"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

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

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

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

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

labor-qualified-tips-w2-reporting differentiator

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

labor-native-payroll differentiator

"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

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

labor-shift-swap-workflow differentiator

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

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

labor-server-performance-metrics differentiator

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

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

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.

inventory-theoretical-vs-actual differentiator

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

inventory-realtime-depletion differentiator

Depletion derives from POS sales polling into theoretical usage; near-real-time modifier-level depletion is not documented.

inventory-86-auto-sync differentiator

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

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

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

inventory-vendor-catalogs-edi differentiator

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

inventory-invoice-ocr differentiator

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

inventory-price-change-alerts differentiator

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

inventory-par-auto-suggest differentiator

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

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

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

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

inventory-lot-traceability

Not documented on public pages.

inventory-shelf-life-expiry

Not documented on public pages.

inventory-bar-partial-bottle

A bar-management partner category exists, implying partner delivery; no native capability documented.

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-native-not-partner differentiator

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

inventory-menu-margin-linkage differentiator

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

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

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

reporting-pmix-modifier-level

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

reporting-comps-voids-audit

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

reporting-cash-over-short

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

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

reporting-server-scorecards differentiator

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

reporting-channel-profitability differentiator

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.

reporting-multiloc-drilldown differentiator

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

reporting-custom-report-builder differentiator

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

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

reporting-raw-warehouse-export differentiator

Unknown stands for general availability, but the reasoning needs correcting and it is close to partial. R365 documents "Secure Data Share" — a direct Snowflake share giving analytics teams standing access to unified POS, sales, labor and inventory data "without API pipelines, CSV exports, or scheduled syncs", listed as one of three integration surfaces in the developer hub. It was announced 2026-05-12 and is stated to be early-access via R365 Chef's Table, with no published pricing or GA date — hence not yet a scoreable yes. adversarially verified

reporting-public-api differentiator

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

reporting-webhooks differentiator

No public API documentation to verify against.

reporting-api-not-upcharged differentiator

No published API commercial terms.

reporting-tier-paywall differentiator

Essential/Professional packaging exists but the feature split is published only as an unreadable image.

reporting-history-retention differentiator

No published retention window for transaction-level detail.

reporting-anomaly-alerts differentiator

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

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

reporting-guest-cohorts differentiator

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

reporting-sales-forecast differentiator

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

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

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

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

multi-location-local-override-policy differentiator

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

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

multi-location-scheduled-publish differentiator

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

multi-location-new-store-template differentiator

No published cloning template or time-to-open figure.

multi-location-corp-vs-franchisee-roles differentiator

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

multi-location-royalty-calculation differentiator

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

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

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

multi-location-normalized-item-rollup differentiator

"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

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

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

multi-location-multi-brand differentiator

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

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.

multi-location-multi-currency-locale

Mobile app supports English and Spanish; multi-currency consolidation is not documented.

multi-location-config-audit-log differentiator

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

multi-location-enterprise-sso differentiator

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

multi-location-enterprise-api differentiator

R365 Connect has no public documentation to verify cross-location transaction-level access.

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

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

extensibility-api-access-cost differentiator

No published API commercial terms.

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

extensibility-free-sandbox differentiator

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

extensibility-oauth-partner-apps

No public authentication documentation.

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

extensibility-webhook-reliability differentiator

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

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

extensibility-menu-write-api differentiator

Whether recipe/item objects are writable via R365 Connect is not documented.

extensibility-data-symmetry differentiator

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

extensibility-published-rate-limits

Checked 2026-08-04: the API overview (docs.restaurant365.com/docs/r365-api), the R365 Public API page (/docs/r365-public-api), the /apidocs Developer Hub landing, and the full public docs index (llms.txt — zero hits for "rate limit") publish no numeric quota, throttling behavior, 429 semantics or rate-limit headers. Not scoreable as no: the per-endpoint API reference sits behind CSM-issued credentials and could not be read, so a limits page may exist behind that gate — but nothing publicly published meets the claim.

extensibility-doordash-preferred differentiator

DoorDash's own newsroom announcement names the 2026 Preferred Integration Partner cohort in full - Checkmate, Chowly, Deliverect, Otter, PAR, Qu, Square, Stream, Toast and UrbanPiper. Restaurant365 is not among them, and R365 publishes no DoorDash order integration of any kind; third-party delivery reaches R365 as imported sales and fee data rather than as injected orders. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-08

extensibility-first-party-delivery-integrations differentiator

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

extensibility-middleware-compatibility

Aggregation middleware endpoints are not enumerated on public pages.

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

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

extensibility-bi-data-warehouse differentiator

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

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

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

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

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

extensibility-data-portability-exit differentiator

ToS affirms data ownership but specifies no export mechanism or format at contract end.

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

reliability-offline-card-auth differentiator

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

reliability-offline-decline-liability differentiator

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

reliability-lan-degraded-multi-terminal differentiator

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

reliability-local-transaction-engine differentiator

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

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

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

reliability-sync-conflict-handling

Mobile counts sync on reconnect but conflict resolution behavior is not documented.

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

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

reliability-contractual-uptime-sla differentiator

Rolling uptime percentages are published, but no contractual SLA percentage with service credits was located in the public MSA archive.

reliability-incident-postmortems

Incident history with statuses is published; written root-cause summaries were not verified.

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

reliability-onsite-install differentiator

Paid Expert Services and a find-an-expert accounting-partner network exist; on-site go-live support is not documented.

reliability-menu-build-service differentiator

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

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

reliability-backup-restore

No published RPO/RTO or self-serve backup/restore.

reliability-pci-dss-4-attestation

No public trust center or AoC located, though R365 does move money on the AP side.

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

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

reliability-failover-terminal-role differentiator

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

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

commercial-month-to-month-contract differentiator

Term not published; MSA PDFs are posted but terms were not extractable.

commercial-no-early-termination-fee differentiator

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

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

commercial-processing-not-bundled differentiator

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

commercial-interchange-plus-published differentiator

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

commercial-rate-increase-clause differentiator

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

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

commercial-module-unbundling differentiator

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

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

commercial-hardware-not-locked differentiator

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

commercial-implementation-fee-published

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

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

commercial-export-customer-and-loyalty differentiator

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

commercial-post-termination-export-window differentiator

No retrieval window stated in the public ToS.

commercial-data-ownership-clause differentiator

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

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

commercial-pci-p2pe-tokenization

No cardholder data entry surface, and no published PCI posture for the AP payment rails.

commercial-pci-dss-4-controls

No public documentation of MFA enforcement or script-integrity controls.

commercial-soc2-attestation

Unknown upheld, and now more firmly. An "R365 Security Controls" white paper is referenced in the public docs index summarising data protection practices, but no SOC 1 / SOC 2 / ISO 27001 attestation, trust center, or AoC was found in docs or on the open web. A vendor-authored controls summary is not an attestation. adversarially verified

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

commercial-wcag-kiosk-accessibility differentiator

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

commercial-dual-pricing-compliant differentiator

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