Vendors / Enterprise & chain restaurant POS
PAR POS / Brink POS
PAR POS / Brink POS (PAR Technology Corporation)
dossier live
- Claims in scope
- 314
- Scored
- 314
- Assessed
- 311
- Unknown
- 3
- Not applicable
- 0
- Values challenged
- 103
Identity
- Owner
- Independent public company. PAR Technology Corporation (NYSE: PAR). NOT merged with NCR Voyix. PAR closed its own acquisition of Bridg (identity resolution / shopper intelligence, from Cardlytics, ~$27.5M in stock) on March 24, 2026. Punchh (loyalty) and Data Central/PAR OPS are PAR-owned.
- Parent
- PAR Technology
- Founded
- PAR Technology Corporation founded 1968 (New Hartford, NY). Brink Software acquired by PAR in 2014; Brink POS renamed "PAR POS" and PAR MENU renamed "PAR Ordering" in a September 12, 2024 product rebrand (https://www.businesswire.com/news/home/20240912457425/en/PAR-Technology-Reintroduces-Core-Products-With-New-Brand-Names).
- Scale
- Q1 2026 (reported May 7, 2026): total revenue $124M, +19% YoY; ARR $330.1M (+16% total, +11% organic) split $198.3M Engagement Cloud / $131.8M Operator Cloud; 199,300 total active sites supported by subscription ARR. Source: https://partech.com/wp-content/uploads/2026/05/050726-PTC-Earnings-Release-Q1-2026-Final.pdf. Marketing claims Brink/PAR POS deployed in 21,000+ restaurant locations (claim-level). Anchor logos: Burger King North America exclusive POS software provider (Oct 2023), Zaxby's, and Papa Johns — 3,200 U.S. restaurants for POS and OPS announced Jan 12, 2026 (https://www.businesswire.com/news/home/20260112168759/en/Papa-Johns-Partners-with-PAR-Technology-to-Power-POS-and-OPS-Transformation-Across-3200-U.S.-Restaurants).
- Who it is for
- Enterprise and mid-enterprise multi-unit QSR and fast casual — realistically 20+ locations, with the sweet spot at national/regional chains and franchise systems in the hundreds-to-thousands of units. PAR's own back-office page states PAR OPS is "ideally" suited to operators with 20+ locations. Independents and single-unit operators are not the buyer; PAR sells top-down to brand/corporate IT, not to owner-operators.
- Site
- https://partech.com/solutions/cloud-pos/
Pricing
transparency: quote-only · unit: unknown · processor lock-in: no
- Software
- quote-only. PAR publishes no pricing page and no dollar figures anywhere on partech.com; every product page routes to "schedule a demo" or 1-800-382-6200. Third-party roundups circulate a "$90/month plus $50 per additional terminal" figure — that number appears only on review-aggregator sites, is not sourced to PAR, and should not be treated as PAR's price. PAR OPS is described as having "modular pricing options" with no amounts given.
- Card processing
- quote-only. PAR Payments markets "simple, fair, transparent... payment processing" but publishes no rate, no interchange-plus markup, and no per-transaction figure (https://partech.com/solutions/payment-services/).
- Contract
- three years initial, auto-renewing one year at a time — PUBLISHED, and the previous 'no publicly accessible MSA' sentence was stale (corrected 2026-08-10). The Subscription Services Agreement (v2.0, 11.14.25) is posted ungated at partech.com/terms-and-conditions/; section 12.a runs the term three years and continues 'automatically renewing for successive periods of one (1) year at a time (each a "Renewal Term"), unless and until Customer provides written notice of cancellation to ParTech at least 30 days prior to the first day of any Renewal Term', subject to 'a different term ... agreed to by Customer pursuant to an Order or a Pricing Addendum'.
- Early termination
- unknown — not published.
API posture
public API: partner-gated
- Cost to integrate
- unknown. PAR operates a public partner directory of 291 listed partners (https://partech.com/partner-ecosystem/) but publishes no referral fee, revenue share, per-location partner fee, or certification cost anywhere in public documentation.
- Webhooks
- Partial and lopsided. A Webhooks Manager exists and is publicly documented, but the documented event families are Punchh/guest-side (guest create, update, delete) — https://developers.partech.com/docs/dev-portal-webhooks-manager/8c18e3660f73f-event-guest. For POS order data the documented pattern is POLLING, not push: the Brink best-practices page tells integrators to call GetOrders/GetShifts with a ModifiedTime filter and GetLastModifiedTime before re-pulling settings. No HMAC signature scheme, retry policy, or replay log found in public docs.
- Data export on exit
- Good, and BOTH halves of the previous sentence were wrong — corrected 2026-08-10, since the Subscription Services Agreement (v2.0, 11.14.25) publishes each one. A POST-TERMINATION WINDOW IS PUBLISHED: section 11.e, 'Return of Customer Data/Transaction Data' — 'Provided Customer has paid all Fees and other amounts due under this Agreement, ParTech will extend Customer's access to the ParTech Services for a period of sixty (60) days beyond the expiration or early termination of this Agreement', during which the Customer may extract data. A DATA-OWNERSHIP CLAUSE IS PUBLISHED: section 11.c — 'Customer has and shall retain sole and exclusive title and ownership of all information and data, including all derivatives and transformations thereof, input by Customer'. Practically, an operator pulls orders/sales/labor/settings through the API while the account is live, and API credentials (AccessToken + LocationToken) are provisioned by PAR per location — so the sixty-day extension is what keeps export from being gated on PAR keeping the account enabled, and it is conditional on all fees being paid.
- Notes
- Read the API posture carefully — PAR's "open API" marketing is stronger than the reality, but the reality is still genuinely better than most of the enterprise-legacy cohort. What is real: the reference docs are readable with no login, no NDA, and no sales call; OpenAPI documents are downloadable; Postman collections and client libraries (Shell/Ruby/Node/PHP/Python) are published; and rate-limit guidance is published as specific numbers — 5 concurrent calls with 2-3 minute spacing on multi-tenant servers, 10 concurrent with 1-minute spacing on single-tenant, save batches capped at 100 and delete batches at 20 with <=5 requests/minute, price changes explicitly not batchable (https://brinkapiportal.parpos.com/bestpracticeandfaqs). What is not real: self-service credentials. There is no signup-and-get-a-key flow. Auth is a static header token pair (Authorization: Token token=LOCATION_KEY, btoken=BUSINESS_KEY on the Punchh side; AccessToken + LocationToken on the Brink side) — not OAuth 2.0, no operator-granted scopes, no individually revocable per-app grants. The API account must be provisioned against each specific location by PAR, which also means multi-location access is a credential-management problem rather than one authenticated call. The core POS API surface is still SOAP/XML/WSDL (api2.brinkpos.net/Ordering.svc, api4.brinkpos.net), with REST layered on in the newer portal. Write coverage is asymmetric: SaveItems, SaveModifierGroups, SavePriceChanges and UpdateItemPrice exist, but menu structure is exposed read-only via GetMenu.
Capabilities
Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.
Order capture & FOH workflow
Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.
order-capture-floor-plan-editor
Brink models tables and sections but not a floor plan. Settings2's Table Type carries exactly four fields - Id, Name, "Capacity: Allowed number of seats for this Table", IsActive - and Settings.svc's Section Type carries only Id and Name (brinkapiportal.parpos.com/settings#SectionTypeTable). Ordering.svc's GetParty is "to retrieve an open Party at the location" keyed on TableId, and NewOrder carries a SectionId, so tables and sections are live operational objects. Shortfall: across all 659 documented operations and types there is no table shape, no x/y coordinate, no saved-layout object and no field assigning a section to an employee - and the schema does model geometry where it exists (DestinationDeliveryZoneCoordinates carries Latitude and Longitude). Nothing on cdn.parpos.com's published document index, the 5.16/5.16r2 release notes or the Features QRGs mentions a floor-plan or table-layout editor. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#TableTypeTable · retrieved 2026-08-08
Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.
order-capture-seat-level
The 5.16r2 Admin Portal Config Guide documents seat-level order capture end to end: the Table Service job option "Group Items by Seat: Order items displayed on the Order List control are grouped by Seat Number. Pressing the 'Next Person' button on the register advances to the next seat"; a register "Change Seat" button behavior that "Changes the seat of the select items in the order list" (unsent items only); "Show Seat Information: Displays table and seat numbers"; and "Show Sub-Total by Seat" on checkout. The Split Order screen additionally supports "moving items between the orders, splitting individual items" so a check can be split by seat after entry. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.
order-capture-coursing-hold-fire
Hold and on-demand release exist as register button behaviors; a course model does not. The 5.16r2 Admin Portal Config Guide's register behavior table documents Hold - "Places selected order items on hold, to be sent at a later time" - with Clusivity ("Inclusive of the order items selected, or Exclusive of the order items selected") and Release Type ("Manual: Order items will be held until employee explicitly releases", "Prompt: Employee must enter hold minutes", "Specific: Predefined hold minutes"); Release - "Releases selected items that are currently being held so that they can be manually sent to the kitchen"; and Send Order Items - "Sends to the kitchen selected unsent order items, which are not being held, on the current order". The KDS renders the state: Kitchen View Format has "Held Items: Color of order items that are currently being held". Shortfall: there is no course entity. Items are held by ad-hoc selection or a hold-minutes timer, not assigned to a named course, and there is no fire-next-course action that releases one course; "course" occurs zero times in both the 8,425-line guide and the 1.75MB / 659-anchor API portal dump, and the Order and OrderItem types carry no course or fire-group field. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
The Admin Portal guide documents "Split Order": "Opens 'Split Order' screen, which allows for adding new orders to the current party, moving items between the orders, splitting individual items, and combining (un-splitting) split items," gated behind a "Split Check" security-level permission. Shortfall: even N-way split, arbitrary dollar/percentage-amount split, and merge behavior after a partial payment has been taken are not itemized anywhere in the guide — only free-form item-level splitting/combining is described. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
Card pre-authorisation with a configured amount is documented. The Integration Settings Portal User Guide (cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf), under Payment Device Configuration > ParPay Settings (5.0i+, updated 5.0L & 5.0m), lists "Enable Pre-Authorization (5.0m+) - Enables the server to initiate a pre-authorized [transaction]. If selected, a [default amount] must be entered. For detailed information, please see the 5.0m Release Notes (MH1-792)." The PAR Pay API (developers.partech.com/docs/par-pay/) backs this with POST /creditcard/v1/preauth ("Preauthorize a credit card transaction without capturing funds"), POST /creditcard/v1/capture and POST /creditcard/v1/void. Shortfall: none of the 26 PAR Pay operations is an incremental or top-up authorisation, and no PAR document describes re-authorising a growing tab or auto-closing stale tabs at end of day - the only tab-related item in the Admin Portal guide remains the "Can Access any Tab" permission. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.
order-capture-transfer-audit
The Admin Portal guide documents a "Transfer Items"/"Transfer Party" register behavior: "Opens the Transfer Party window that allows the current employee to select tables or tabs to transfer to another employee." Shortfall: no dedicated audit report or log entry naming both the transferring and receiving employee for a transfer action was found — the guide's audit reports (Manager Override Detail, Void Details, etc.) cover void/discount/promotion/surcharge approvals, not table/tab transfers. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.
order-capture-native-handheld
PAR Tablet: rugged Gorilla Glass, sealed, NFC/RFID for card processing, 10-hour battery; runs PAR POS natively. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
PAR's In-Store Resilience release notes (Rev 05, June 2025) document offline order entry and enumerate the exceptions. Validation procedure: "Turn off the internet connection... The primary and all secondary registers will continue to function but in offline mode, just as they currently do"; with the primary register's cable pulled, "the backup primary swiftly assumes control and continues operating in offline mode. The remaining secondary registers subsequently recover and also operate in offline mode." FAQ: "What occurs if the location completely loses its internet connection? A: If internet connectivity is lost, offline mode operates normally with the primary register acting as the host as it does today." What does NOT work offline is published in the same FAQ: online ordering ("online orders will still fail"), changeset publishing, End of Day, and synchronising historical data to the cloud; guardrails also block Clocking Out, Checking Out and Cash Drawer Assignment on a backup primary for a default 15 minutes. Single-register locations "cannot implement this feature - the primary register transitions to offline mode after a connection loss, as it currently does." This supersedes the earlier reading of the API FAQ's "Accept Orders When Master Offline", which is a cloud-side setting about inbound API orders only. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator
order-capture-qr-same-check
NEW (not moved). NEW SURFACE: product-docs.partech.com (Scalar docs; robots Allow: /; llms.txt 156,164 bytes lists 546 URLs = sitemap.xml 546 <loc>; par-pos section 164 URLs, 163 fetched as markdown via the .md suffix at 200, 1 slug (ingenico Move 5000 Canada) mangled by my extractor; the rest are Punchh 374 and Guest360 7). Found via crt.sh %.partech.com (301 names). The native QR feature on Brink is PAY, not ORDER: "CheckPlease QR Code Contactless Payment Setup Guide": "This Contactless Payment feature lets guests pay for their order by scanning a QR code printed on the order receipt ... redirects the guest to a CheckPlease webapp, where the guest sees all ordered items along with the amount due." "This feature is native to PAR POS and PAR Pay and is powered by CheckPlease." Other QR hits are the receipt-footer URL QR (Options > Printing "Show QR Code"), the loyalty receipt QR (5.16r2 BRNK-65732), Punchh QR payment and the Revenu Quebec receipt QR (POISON for this claim). No guest QR ordering onto a server-opened check in the 163 pages. Retrieved 2026-09-16. || 323rd: NEW (323rd): the QR setting itself, as shipped, is a PAYMENT toggle. NEW SURFACE (323rd): the LABEL DICTIONARY of the production Brink Integration Settings Portal - https://prod.integrations.parpos.com/assets/i18n/en.json, fetched anonymously 2026-09-17, HTTP 200, content-type application/json, 21,316 B, body opens {"ENTITY":{"COMPCARD":{...}. The 319th held this app's minified bundle (main.c1e78e4876a8ad7a.js, 1,795,497 B, re-fetched byte-identical today) but not this file, which renders every field name the portal shows. SOFT-200 CONTROL: on this host /assets/config.json, /assets/i18n/en-US.json, /main.c1e78e4876a8ad7a.js.map and /zzz-nope.js.map ALL return the 49,476-byte Angular index.html shell as text/html, so there are no source maps here and the en.json 200 counts only because it differs in length, type and first bytes. The dictionary's ENTITY key is a closed list of the 13 integration types the portal configures: COMPCARD, CONTACTLESSPAYMENT, CREDITCARDOPTIONS, CREDITPROCESSOR, EXTERNALKITCHEN, EXTERNALPAYMENT, GIFTCARDOPTIONS, GIFTPROCESSOR, LOYALTY, ORDERSTATUSEVENT, PAYMENTDEVICE, PERIPHERAL, SMS. ENTITY.CONTACTLESSPAYMENT is the only QR-bearing entity and its complete field list is "APIURL": "API URL", "CONTACTLESSPAYMENTPROVIDER": "Type", "ENABLEQRCODEPAYMENT": "Enable QRCode Payment", "ENABLETEXTTOPAY": "Enable Text-to-Pay", "LOCATIONTOKEN": "Location Token", "SMSTEMPLATE": "SMS Template", "WEBAPPURL": "WebApp URL"; the bundle pins the provider list to a single value, `contactlessPaymentProviders=[Eg.CheckPlease]`. No guest-ordering, cart, menu, add-to-check or table-join field exists on the entity, and no separate QR-ordering entity exists among the 13. This confirms in the running application what the CheckPlease setup guide says, and adds nothing that would let a guest write items onto a server-opened check. BOUND: this is one production app (per-location integration configuration), not a census of Brink, so no `no` is published on it. Retrieved 2026-09-17. || 326th: 326th: product-docs.partech.com fetched to 100% of its own sitemap for the first time - 546 <loc>, 545 doc pages retrieved as markdown at HTTP 200 with zero failures, 4,942,116 chars - which adds the 374 Punchh and 7 Guest360 pages that every prior pass omitted (they had walked only the 164 par-pos URLs). `qr` fires 296 times in 57 of the 545 files and the Punchh half of the corpus is all loyalty scanning, not ordering: the heaviest pages are checkplease-qr-code-payment-setup (37), Punchh-Single-Scan-Flow-Feature (13) and PARPOSPunchhLoyaltySetupInstructions (5). Nothing in the newly-added 381 pages puts a guest-scanned QR onto a server-opened check; the Punchh single-scan flow is a loyalty-identification and redemption scan presented at the register. Also new and empty for this cell: the 798-document anonymous WP REST census of partech.com (types enumerated at /wp-json/wp/v2/types, every public type paged to x-wp-totalpages), where `qr code` has 30 hits in 18 documents, all payment/marketing-offer QR, and `at-table` 4 hits, none an ordering surface. Retrieved 2026-09-18. || 329th: 329th: two NEW surfaces, neither carries the same-check conjunct. (1) The unlinked legacy doc index on cdn.brinkpos.net reached from the Brink Admin Portal login page (Documentation.html, 5,728 B; nonsense control 403; its robots 301s to cdn.parpos.com's generic 'User-agent: * / Disallow: /', read like a browser under the owner's order). Its PAR Pay section still offers only 'CheckPlease QR Code Payment Setup Guide' (fetched, 953,136 B) - the QR feature on this product is a PAYMENT QR printed on the order receipt, which is what prior passes already recorded; there is no guest-ordering QR document anywhere in the index, in StepByStepGuides.html's 72 workflow guides (which do include 'How do I Start a New Order?', 'How do I Split an Order?', 'How do I Reopen an Order?') or in HowToVideos.html. (2) PAR's own retired Brink partner marketplace, parpospartners.partech.com (NXDOMAIN today, recovered via Wayback CDX, 54 URLs: 29 partner pages + 15 /t/brink-categories/ pages). Its 'Online Ordering' category contains OneDine, whose PAR-hosted card reads 'Are you ready to add tablets, kiosks, QR code ordering, online ordering and MORE to your business? Without needing to change from your PAR POS, gift card provider, loyalty provider, or credit card processor?' - so a QR-ordering partner was certified for Brink, but the card states nothing about whether items land on the SAME OPEN CHECK as server-entered items rather than a separate ticket, which is the whole claim. Paerpay appears in the same marketplace under 'Payments', not ordering. STILL UNKNOWN. Per-cell re-greps run this pass over 2,251 docs / 35,773,075 chars of every par-brink corpus on disk (545 product-docs, 531 developers.partech.com, 1,102 supportcenter Aura bodies, the 798-doc WP census, 37 app bundles, 15 API specs, the 5.16r2 Admin Portal guide): tokenised `open check` 2 hits (both Punchh third-party-POS install guides, POISON), `existing check` 0, `same check` 0 (one hit is a store-group validation sentence), `add to an existing order` 0, `scan to order` 0, `order and pay at the table` 0, `table ordering` 1 (a Vapiano case study about a third party's tablets). Retrieved 2026-09-18. adversarially verified
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
First-party kiosk with real-time POS menu sync claimed; no ADA/accessibility conformance documentation published. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
"Drive Thru Mode" plus a drive-thru solution suite; G5 drive-thru audio and order confirmation boards. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
PAR sells a first-party Drive-Thru Timer product for monitoring wait times. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator
order-capture-voice-ai
The claim's second limb is now met, thinly. PAR's own support centre publishes a categorised roster of its API integrators - the article is titled "Where can I find a list of the current PAR Strategic Partners / API Integrators?" - and among its category headings is one reading "Voice AI", under which exactly one integrator is named: "Converse Now". This is PAR naming a voice-AI integrator in a first-party document, which the 2026-08-08 pass could not find on partech.com/integrations/ because that page renders its category filter client-side; the same roster also settles adjacent questions the record had left open, listing "Omnivore" under "Universal API" and QSR Automations as the single Kitchen integrator. Shortfall, and it is why this is not a yes. PAR ships no first-party voice agent - nothing in the 5.16r2 Admin Portal Config Guide, the legacy Brink API portal's 659 operation and type anchors, or developers.partech.com describes one. And the roster is a bare list of names: it states no channel (phone or lane), no certification tier, no integration reference, and no statement that a voice order is injected without staff transcription. A bare roster row is a floor on who integrates, not a description of what the integration does. https://supportcenter.partech.com/s/article/where-can-i-find-a-list-of-the-current-par-strategic-partners-api-integrato · retrieved 2026-09-12 adversarially verified
Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator
order-capture-throttling
Brink publishes channel-scoped lead- and prep-time control but not capacity throttling. Settings2's FutureOrderingOptions type enumerates AllowFutureDateOrdering, Destinations ("Destinations that future ordering can be directed to" - the per-channel axis), IsEnabled, LeadTimeThresholds, MaximumDaysInAdvance, MinimumLeadMinutes ("Minimum amount of time that the order pickup time needs to be from placement time"), MinimumPrepMinutes ("Minimum amount of time before the order pickup time allocated at which the order is open on the register and sent to the kitchen"), PrepTimeThresholds and RequiredDepositPercent. Shortfall: LeadTimeThreshold and PrepTimeThreshold each carry a single integer of minutes (LeadMinutes / PrepMinutes) and nothing else - there is no order-count or capacity limit per time slot, and no field that extends the quote when kitchen load crosses a threshold. The word "throttl" does not appear anywhere in the 1.75MB portal dump, the 5.16/5.16r2 release notes or the Features QRGs; 5.16r2's only related addition is manual - "Operators can manually set a custom prep time on any future order, replacing the default calculated prep time" (NUC-2117). Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#FutureOrderingOptionsTypeTable · retrieved 2026-08-08
Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.
order-capture-scheduled-orders
The cited page's only supporting word is "preordering" in a list of conversion tools. That is thin for a 'yes' on scheduled orders, and fire-time injection is admittedly undocumented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01 adversarially verified
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
Catering appears only as a destination in the menu-sync channel list, and "PAR Catering" is a separate offering whose Learn More links off to punchh.com — i.e. a distinct product, not a documented capability of PAR Ordering. No catering order-management functionality is described. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01 adversarially verified
Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator
order-capture-order-ready-signal
Verified. DoorDash's DPIP requirement list expressly includes "Order Ready Signal" as one of eight mandatory high-quality features, and PAR is named in the 2026 roster alongside Checkmate, Chowly, Deliverect, Otter, Qu, Square, Stream, Toast and UrbanPiper. Scope caveat: this evidences the DoorDash-channel signal only, not a guest-facing or in-store ready notification. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01 adversarially verified
Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.
order-capture-void-comp-controls
The Admin Portal guide documents the full chain: a Void Reasons list ("Refund reasons are listed for the employee to choose when the 'Refund' button behavior is executed"; five default reasons include 86'd Item, Kitchen Error, Server Error, Test Order, Waste); role-gated SecurityLevel permissions (VoidItems, ApproveDiscounts, already cited elsewhere in this record); and an exception-report trio — "Void Details" (grouped by employee, sorted by void time), "Void Summary" (totals by void reason), and "Manager Override Detail" ("Lists details regarding all manager override actions, including: Approval Time, Login User, Button Name, Button Action, Approval User, and Approval Method"). https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Menu, modifiers & pricing engine
Payments & money movement
The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator
payments-processor-choice
PAR's own DataCap EMV USA Payment Matrix (published on PAR's documentation index at cdn.parpos.com) says "Brink POS supports several payment gateway solutions and processors for accepting EMV card payments" and lists the supported processors/hosts for the USA by name: Chase Paymentech, Global Payments Inc., Mercury Payment Systems, First Data Rapid Connect, Heartland Payment Systems, TSYS, Vantiv, WorldPay, BluePay, Elavon, Monetary, each with its certified devices and per-processor feature table. PAR's own gateway (PAR Pay) is one option among these, not a precondition. Same index also publishes separate FreedomPay Setup and Configuration and Tender Retail Payment Gateway Configuration guides. Caveat: this matrix is a 2020 revision, still the current version PAR links. https://cdn.parpos.com/docs/Brink%20DataCap%20EMV%20USA%20Payment%20Matrix%20.pdf · retrieved 2026-08-06 · not refetchable · site policy · graded B when read adversarially verified
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
Payment services page markets "transparent" pricing but publishes no rate, markup, or per-transaction figure. Not published publicly. https://partech.com/solutions/payment-services/ · 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
The Integration Settings Portal User Guide's ParPay Settings section documents "Non-Cash Adjustment Enabled - Check to charge guests the credit card processor interchange fee when paying with credit card", so a native cash-discount-style mode does exist on PAR's own payment integration. Shortfall: it stores no second price. Settings2's Items type has a single Price plus an item-scoped PriceLevelId (PriceLevel itself being Id/Name/Price), and Settings2's PaymentOptions decomposes into CreditCardOptions, ExternalPaymentOptions, GiftCardOptions, RoundingOptions, TipAndSignatureOptions and PayAtTableOptions with no dual-price or cash-price field in any of them. No PAR document describes printing both a cash total and a card total on the guest check or receipt. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
The prior assessment was wrong that no Surcharge configuration object is published - Settings.svc's GetSurcharges returns a fully enumerated Surcharge type: Amount, AutomaticallyApply, Days, EndDate, EndTime, EnforceDateRanges, EnforceDays, EnforcePartySize, EnforceTimeRanges, Id, LimitDestinations, LimitSections, MaximumPartySize, "Method: 0 = Fixed Per Order, 1 = Percentage Per Order, 2 = Fixed Per Item, 3 = Percentage Per Item", MinimumPartySize, Name, Prompt, StartDate, StartTime, TaxIds, and "TerminalTypes: 0 = None, 1 = Register, 2 = Web Ordering, 8 = Web Mobile Ordering, 16 = Web-Service". Every dimension is time, party size, destination, section or terminal - there is no card-type, BIN, product-code, debit or prepaid field, and no percentage-cap enforcement. The one card-aware surcharge PAR ships is the PAR Pay "Non-Cash Adjustment Enabled" checkbox, whose entire documented behaviour is "charge guests the credit card processor interchange fee when paying with credit card" - again no debit/prepaid exclusion and no cap. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings#SurchargeTypeTable · retrieved 2026-08-08
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
EMV credit and debit plus contactless including Apple Pay, Google Pay and Samsung Pay. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01
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
PAR's own Payment Device Configuration section is the supported-device enumeration and contains no phone-as-reader option. It lists exactly eight integrations: ParPay (5.0i+), Pax POS Link (5.0i+), Datacap US EMV (5.0j+), Tender Retail (5.0j+), Elavon (5.0j+), Datacap Canadian EMV (5.0j+), FreedomPay (5.0j+, updated 5.0L) and Verifone Point (5.0j+, updated 5.0L) - every one configured by IP address/COM port/terminal ID against a physical PIN pad. The PAR Pay API (developers.partech.com/docs/par-pay/) exposes 26 operations across credit card, gift card, tokens and OAuth, of which the card-entry paths are /creditcard/v1/purchase, /creditcard/v1/preauth, a hosted iFrame URL and Google Pay configuration - no Tap to Pay on iPhone and no Android tap-to-pay SDK. partech.com/solutions/payment-services/ and /solutions/pos-hardware/ describe Apple Pay, Google Pay and Samsung Pay only as wallets tapped against a PAR terminal. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
PAR Tablet handheld with NFC/RFID card processing; tip prompt and tableside check splitting not documented. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
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
"QR Code to Pay" and "Text to Pay" named as supported payment methods; automatic check closure in the POS not documented. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01
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
The Admin Portal guide documents "Allow Tip Adjust On Register: When tender Type is set to Credit Card or Gift Card and [enabled, staff can adjust] the register via 'Adjust Tips' or 'Adjust Payment' buttons," a CanAdjustTipsFromAnyTill security permission (a manager-level cross-till adjust screen), and Tip Type (Percent/Fixed Amount) configuration for the on-device tip prompt. Shortfall: no documented batch/adjust cutoff window is specified, and pre-auth-then-tip-adjust is not itself named as a supported flow. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator
payments-tip-pooling
The Admin Portal guide documents "Tip Pooling Enabled: Allows for the definition and management of employee tip pools," with per-job "Contribute to Tip Pool" (percentage of compensation) and "Receive Distributions from Tip Pool" flags. The PAR OPS Payroll API (already cited in this record for labor-tip-distribution-audit-trail) separately exposes TipShareHours, TipShareAmounts, TipShareJobWeights and TipShareSettings, producing a per-employee, per-payroll-period distributed tip amount exportable via API. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
Datacap US EMV Settings (5.0j+) in the Integration Settings Portal User Guide document the feature and its limits verbatim: "Support Store and Forward - If credit card terminal is offline, allows customer to still pay with a credit card; transactions are stored and forwarded for settlement when system is back online"; "Force Offline - [enter offline] mode immediately"; "Maximum Number of Offline Transactions - Controls how many transactions are allowed while offline, any value between 1 and 9999 (default = 300)"; "Maximum Transaction Amount - Maximum amount allowed for an offline transaction (default = 500.00)". That is a configurable per-transaction limit and a configurable cumulative limit. Note the capability is carried by the Datacap integration rather than by every processor integration PAR supports. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
The reconnect mechanics and the reporting limb are now published; the liability limb is not. PAR's support centre documents the full store-and-forward upload path: overnight upload to the Aurus host, and on failure "The Aurus Host will attempt to process the transaction 2 additional times spanning 2 calendar days in an effort to receive an ONLINE Approval", then "If after (3) unsuccessful attempts to receive an ONLINE Approval the transaction will be considered DECLINED and will be removed from processing". The reporting limb is partly answered in the same article: an offline-approved transaction "will always maintain this characteristic and can be queried / reported on in StorePlace", so the offline population is flagged and queryable - but that sentence is about offline-APPROVED transactions, and no article states that a transaction declined on its third upload attempt appears in any report. A separate article covers the at-capacity case - "The transaction will be DECLINED with the following response:" and the printed reason "Offline Txn Count Exceeded" (https://supportcenter.partech.com/s/article/what-do-i-do-if-my-device-is-in-offline-store-and-forward-mode-and-it-becom). Shortfall: no PAR document says who bears the loss. "removed from processing" describes the processor's handling, not an allocation of the resulting shortfall between merchant, PAR Payment Services and the issuer, and neither the Sub-Merchant Agreement nor the PAR Pay Service Level Commitment assigns it. Held at partial rather than yes for that reason; the claim is a conjunction and only one limb is met. https://supportcenter.partech.com/s/article/how-does-offline-store-and-forward-mode-work-other-noteable-offline-store-a · retrieved 2026-09-12 adversarially verified
First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.
payments-gift-cards
Physical and digital gift cards supported through PAR Payments with loyalty integration; brand-wide multi-location redemption and online-channel redemption not explicitly documented. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
A dedicated HouseAccounts SOAP service exists in the PAR POS API; per-account credit limits and statement/invoice generation not documented. https://brinkapiportal.parpos.com/ · 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
The Admin Portal guide's Split Order screen supports moving/splitting items across multiple new orders from one party, and the Pay at Table section states a check "can be paid in full or split among multiple guests at the same table." Shortfall: no explicit tender-count cap or confirmation of an eight-plus-way split was found anywhere in the guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.
payments-refund-void-controls
Role gating and approver audit are documented for voids and discounts: Settings2 SecurityLevel carries discrete VoidItems, ApproveDiscounts and DeletePayments permissions, and Sales2 order history attributes both actor and approver (OrderItemVoid.ApproverEmployeeId "Maps to the Id of the Employee who approved this OrderItem"; OrderDiscount carries EmployeeId plus ApproverEmployeeId), queryable via GetOrders. Shortfalls: refunds appear only as Order.IsRefund plus RefundReasonId with no documented approver or refund-specific permission, no no-sale permission or audit object is documented, and no immutability statement exists. https://brinkapiportal.parpos.com/sales2 · retrieved 2026-08-03
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
Chargeback tooling is named as a gateway capability but no dispute workflow is described. The PAR Pay gateway page states 'PAR Pay provides native support for EMV, NFC, EBT, tokenization, customized tip support, and chargeback tooling, enabling modern payment methods without added complexity' — a bare feature-list mention, which is a floor and not a description. Shortfall: nothing published shows a dispute dashboard, a list of open disputes, a response deadline, or evidence assembled from the POS transaction record. Absence control: 'evidence submission' and 'representment' occur ZERO times across all 1,358 documents. Do not conflate this with PAR OPS Recovery (https://partech.com/solutions/insights-and-delivery-solutions/delivery-loss-disputing-recovery/, retrieved 2026-09-09), which is a different artefact: it automates disputing DELIVERY-MARKETPLACE losses with 'DoorDash, Uber Eats, and Grubhub', not card chargebacks with an acquirer. https://partech.com/solutions/payment-services/pay-gateway/ · retrieved 2026-09-09 automated extraction
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 Admin Portal guide documents "Enable Stored Credit Cards: Credit cards can be stored on customer accounts" for the in-store channel. On the digital side, the Punchh Mobile API (already cited in this record) documents Payment Cards/Payments endpoint groups and a secure_tokens endpoint for guest accounts. Shortfall: no explicit "no PAN stored by merchant" statement was found, and phone-order reuse of the same stored card is not documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
A funding cadence is published; a deposit schedule and any faster option are not. The PAR Payment Processing page states PAR provides 'Underwriting, processing, settlement, and funding in one service, with next-day funding standard.' Shortfall: that one clause is the whole of it — no cut-off time, no banking-day rule, no weekend/holiday behaviour and no same-day or instant funding option is published. Absence control: 'deposit schedule' and 'instant payout' occur ZERO times across all 1,358 documents; 'same-day funding' occurs in 2 blog posts, neither a statement about PAR's own funding. Bounded to a corpus frozen 2026-09-09: partech.com's WordPress REST API across all seven public content types (799 documents; the type registry at wp-json/wp/v2/types and the Yoast sitemap index reconcile — the only sitemap entries absent from the REST census are taxonomy archives), the 531-page developers.partech.com sitemap (which equals its llms.txt exactly, so that pair is one table rendered twice and is a FLOOR, not a census), and the 28 OpenAPI documents the per-section llms.txt files name. https://partech.com/solutions/payment-services/payment-processing/ · retrieved 2026-09-09 automated extraction
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
Separate MIDs per location are a documented configuration. The Integration Settings Portal User Guide's Payment Device Configuration gives Datacap US EMV "Merchant ID - Provided by processor" and "Terminal ID - ID unique to location, exposed for all Datacap payment devices"; Elavon adds "Terminal ID - Unique by location" plus Chain and Location; FreedomPay has "Merchant ID - Defined by FreedomPay" and "Terminal ID - Unique by location"; Datacap Canadian EMV the same. Because payment devices are configured per location and linked to registers there, a group can run distinct MIDs per site while reporting rolls up in one Admin Portal (the published report guides include Sales by Destination, Sales by Order Source and Royalties by Location). Shortfall: PAR documents no settlement-routing control of its own - the only bank account and routing number fields in the Admin Portal guide sit on Options > Accounting > Royalties and exist "to appear on the Royalties by Location report", a display field - and nothing describes split settlement or assigning funds to different legal entities from one account. https://cdn.parpos.com/docs/IntegrationSettingsPortalUserGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
cdn.parpos.com/docs/PARPOSSoftwareSecurityFrameworkFAQ.pdf carries a Coalfire Systems letter dated 18 Oct 2022: "This letter affirms that Par Tech has engaged Coalfire Systems, Inc. to perform a Secure Software Assessment in line with the PCI SSC P2PE requirements... The assessment is planned to conclude in early 2023", and "Please feel free to distribute this letter to business partners who need to know the status of your SSF engagement activities." The FAQ answers "What if my auditor requires SSF documentation for POS? ParTech will provide our most recent PA-DSS AOC for POS as well as our Letter of Engagement from our third-party consultant" - so attestation documents are supplied on request. Shortfall: the document PAR offers is a PA-DSS Attestation of Compliance, and the same FAQ records that "The SSF replaced the Payment Application Data Security Standard (PA-DSS) on October 28, 2022"; no completed SSF validation, no current PCI DSS 4.x AoC and no PCI SSC P2PE validated-solution listing is published. The only newer PCI artefact on PAR's document index is PARPay2024PCIUpgrade.pdf, a device-upgrade notice warning that "failing to comply with this upgrade will result in your devices losing the ability to process transactions". https://cdn.parpos.com/docs/PARPOSSoftwareSecurityFrameworkFAQ.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Kitchen & production
Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.
kitchen-station-routing
First-party KDS is part of the platform and PAR markets kitchen management; per-location operator-configurable routing rules not documented. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.
kitchen-expo-consolidation
The 5.16r2 Admin Portal Config Guide documents native expo: kitchen queues have an 'Is Expediter' option that 'displays check marks beside order items that have been bumped from all kitchen queues that do not have Is Expediter enabled' — the expo view consolidates the order and tracks per-station bump state — plus 'Bump From Other Kitchen Queues' (optionally limited to selected queues), an Order Expediter Action fired when the order is bumped from the expo queue, and Options > Kitchen expo-sequence controls (Prioritize Expeditor Only Items; identify/rearrange out-of-sequence orders on expo). https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read
Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator
kitchen-course-firing
Items can be held and fired to the kitchen on demand, but not by course and not from the expo screen. The 5.16r2 Admin Portal Config Guide's register behavior table documents Hold ("Places selected order items on hold, to be sent at a later time"; Clusivity inclusive or exclusive of the selected items; Release Type Manual - "held until employee explicitly releases" - Prompt for hold minutes, or Specific predefined minutes), Release ("Releases selected items that are currently being held so that they can be manually sent to the kitchen") and Send Order Items ("Sends to the kitchen selected unsent order items, which are not being held, on the current order"). The Kitchen View Format tab carries "Held Items: Color of order items that are currently being held", so the KDS distinguishes the state. Shortfall: no course object exists to assign items to - "course" occurs zero times in the 8,425-line guide and in the 1.75MB API portal dump - the release is by manual selection or a hold timer rather than a fire-next-course action, and the firing controls are register button behaviors; Kitchen.svc's only operations are the read-only GetOrderBumpTimes and GetOrderItemBumpTimes, so nothing fires from the expo screen in the documented surface. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
Per-item cook times are not configurable in Brink. The Settings2 Items type - the complete item record used by GetItems and SaveItems - carries kitchen-facing fields (AlternateKitchenName, BlinkInKitchen, KitchenColor, KitchenBackgroundColor, ModifierRouting, PrinterGroupId, VideoGroupId) but no cook time, prep time or start-offset field of any kind. The only minute-valued prep fields in the whole schema are FutureOrderingOptions.MinimumPrepMinutes and PrepTimeThreshold.PrepMinutes ("Minutes for a prep time threshold"), which govern when a scheduled future order opens on the register - one value for the location, not per item. Kitchen.svc reports a per-item FireTime (OrderItemBumpTime) but that is read-only history, and the Admin Portal guide's Kitchen Queue Thresholds tab only drives colour/flash escalation once an order exceeds a target time. Nothing staggers item start times so an order finishes together. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#ItemsTypeTable · retrieved 2026-08-08
Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator
kitchen-order-throttling
No kitchen-load pacing exists. The 5.16r2 Admin Portal Config Guide's kitchen configuration screens are Kitchen Queues, Kitchen Views, Thresholds and Load Balance: Thresholds sets visual/audible escalation (Color, Seconds, Flash, Mode) once an order exceeds a target time and changes nothing about order release, and Load Balance distributes orders across kitchen views by time-of-day override, not by capacity. The API side agrees - Settings2's KitchenQueue is Id/Name, KitchenVideoGroup adds only colour and routing overrides, and Kitchen.svc's two operations are read-only bump-time reporting - so there is no configurable order-volume or ticket-time threshold that delays release or extends a quote. "Throttl" occurs zero times in the 1.75MB portal dump, the 5.16 and 5.16r2 release notes, the Features QRGs and on partech.com. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#KitchenQueueTypeTable · retrieved 2026-08-08
Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator
kitchen-channel-pause-propagation
Item-level 86 propagation has a documented mechanism; store pause does not. Ordering.svc publishes GetUnavailableItems, "to retrieve the list of item IDs that are active but unavailable at the location on current business date... can be filtered basis specific destination as well", plus GetItemAvailability and UpdateItemAvailability with QuantityAvailable - so a marketplace integration can read 86s made in the POS, per destination, and DoorDash's DPIP requires exactly this ("86 items + Item Polling"). Shortfall: propagation is pull-based and integrator-implemented - the legacy PAR POS API portal exposes no webhook, callback, event or subscription surface at all (zero occurrences across the 1.75MB dump; PAR's webhooks manager on developers.partech.com is documented for Punchh guest/engagement events, not POS availability) - there is no store-level pause object anywhere in the schema, only per-item availability, and PAR publishes nothing about Uber Eats or Grubhub receiving either signal. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/ordering#GetUnavailableItems · retrieved 2026-08-08
Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator
kitchen-order-ready-callback
An order-ready event is pushed to the third-party partner, but no KDS-bump trigger is documented. External Orders API 2.0 publishes six outbound webhooks — order.confirmed, order.rejected, order.ready, order.cancelled, menu.published/unpublished and store.status-changed — and the order.ready operation's description is 'Sent when the order is ready for pickup or hand-off', with an example payload carrying event, order_id, external_reference and timestamp. Shortfall: the claim asks specifically that bumping the order ready on the KDS emit the event, and nothing in the spec or in the PAR KDS material says what raises order.ready — no trigger source, no KDS binding and no state machine tying a bump to the webhook is published. The spec is a floor for prose: of the 28 OpenAPI documents only par-pay's declares `additionalProperties: false` (99 times); the other 27 declare it zero times, so no schema ceiling exists. https://developers.partech.com/docs/eo-api/apis/external-orders-api-2 · retrieved 2026-09-09 automated extraction
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
PAR sells a programmable bump bar alongside its KDS. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
CLAIM: An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station. VERDICT: unknown -> partial/B. The prior notes missed an existing Settings Editor entity (it is also in the 5.16r2 Admin Portal Config Guide pp.136-138, cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf, so this is an unread section, not a new capability). EVIDENCE (NEW SURFACE: product-docs.partech.com (Scalar docs; robots Allow: /; llms.txt 156,164 bytes lists 546 URLs = sitemap.xml 546 <loc>; par-pos section 164 URLs, 163 fetched as markdown via the .md suffix at 200, 1 slug (ingenico Move 5000 Canada) mangled by my extractor; the rest are Punchh 374 and Guest360 7). Found via crt.sh %.partech.com (301 names).): Kitchen Displays page: "Kitchen Key Ingredient Summary: Select which Kitchen Key Ingredient Summary will display on the kitchen display." "Kitchen Key Ingredient Summaries allows you to configure how the key ingredients will display on the kitchen display." Settings: Display Location (None/Top/Bottom/Left/Right), Screen Percentage, Rows, Columns, "Show 0 when BIN is empty: When a key ingredient is defined but there are currently none of the key ingredients ordered, this setting defines what to display on the Kitchen Display. When checked (Default), the key ingredient will display on the Kitchen Display with a value of 0"; "When the number of key ingredients gets to 0, the cell will display the number 0. If the checkbox is disabled, the whole key ingredient cell will be removed from the grid when the number of key ingredients gets to 0."; "Count Color: The color of the digit that shows the ingredient count." Key Ingredients (https://product-docs.partech.com/docs/par-pos/user-guides/settings-editor/items-bulk-price-key-ingredients-keyboard-shortcuts): "Key ingredients print on the kitchen chit or display on Key Ingredient Summary control and are intended to communicate common prep items or ingredients for different order items"; fields Name, Active, Display Text, "Quantity: Number of times each qualifying item counts towards the quantity displayed", Add Item (select items). So a KDS grid shows a live count per operator-defined key ingredient of what is currently ordered, falling to 0. WHY PARTIAL: counts only operator-configured key-ingredient groups of ITEMS (no per-modifier aggregation stated), and the docs do not state the scope is all open tickets on that station (the "BIN"/"currently ... ordered" wording implies it but does not say so). POISON: the Layout button behavior "Key Ingredient Summary: Displays key ingredient summaries for the current order" is the register screen for ONE order, and the printer option "Key Ingredient Summary Placement: Prints a total count for each qualifying key ingredient summary for the sent order items" is per chit; neither is the all-day view. Retrieved 2026-09-16. https://product-docs.partech.com/docs/par-pos/user-guides/settings-editor/kitchen-displays-key-ingredient-summaries-keypads · retrieved 2026-09-16 adversarially verified
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
The Admin Portal guide documents a per-kitchen-queue "Thresholds tab": "Color: Color of the order card border," "Seconds: Number of seconds after the order appears in the queue to apply the threshold style," "Flash: Flash the order card timer," and "Mode: Animate/Switch" — configurable target times with visual color escalation, reinforced by the Kitchen Performance report family which counts "orders bumped prior to each threshold time defined on each kitchen queue" versus those "bumped beyond the last threshold." https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
A designated backup exists: the Edit Printer dialog carries a 'Backup Printer' drop-down (guide p.262), and the 5.16 release notes (cdn.parpos.com/release-notes/5.16ReleaseNotes.pdf) add kitchen-printer reroutes that automatically follow a KDS queue reroute and can be persisted. Shortfall: nothing public states that failover to the backup printer is automatic when a printer or KDS goes offline, or that queued tickets are preserved — the documented 'Reroute Printers' / 'Reroute Kitchen' flows are operator-initiated button behaviors. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
The In-Store Resilience release notes (already cited elsewhere in this record for reliability-offline-kds-printing) state that on complete internet loss "offline mode operates normally with the primary register acting as the host" — all in-store terminals, including kitchen displays, continue operating against the local host rather than the cloud, with kitchen printers configured as attached to specific registers per the 5.16r2 Admin Portal guide. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
Station screens show modifier detail but not build detail. Settings2's KitchenVideoGroup type defines KitchenBackgroundColor as "Background color for all items and modifiers in the video group", and the Items type carries ModifierRouting plus ModifierRoutingOptions and AlternateKitchenName, so modifiers are routed to and rendered on kitchen displays rather than collapsed into the line text. Shortfall: there is no recipe or assembly content to display - ItemIngredient carries only Id, ItemId and "Position: an index of where this ItemIngredient is positioned", with no step text, quantity or portion size, and the Items type has no build-instruction field. The 5.16r2 Admin Portal guide's Kitchen Views sections document ticket-text formatting, thresholds, colours and bump behaviour with no recipe-step or portioning screen. Reference is the legacy PAR POS API Portal, which announces its own eventual deprecation in favour of developers.partech.com/docs/parpos-cloud-apis; the legacy portal is the only host that still serves the full PAR POS operation and type reference as citable text. https://brinkapiportal.parpos.com/settings2#KitchenVideoGroupTypeTable · retrieved 2026-08-08
Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator
kitchen-pizza-fractional-display
Fractional intent reaches the make line as a modifier code, not as a section model. The 5.16r2 Admin Portal Config Guide's Options > Kitchen > General tab reads "Consolidate Like Modifier Codes: Consolidate modifiers into groups based on the modifier code (ADD, NO, HALF, etc.) on both kitchen displays and printed kitchen chits", and the Modifier Codes page defines the object as Name, Id, "Abbreviation: Text to be added to the beginning or end of the modifier name", Applies To (Ingredients / Non Ingredients / Both), Type (Normal, No, Sub, For, On Side), Charge Type, "Enable KDS Font Color: Controls whether the Modifier Code is seen on the KDS in a specified color" and KDS Font Color. So a HALF code is displayed and printed to the kitchen, grouped and optionally colour-coded. Shortfall: it is a text abbreviation, not a placement dimension. The published order model has no section or placement field (NewOrderItemModifier carries none, and "quarter" and "fraction" occur zero times across the 1.75MB / 659-anchor API portal dump), so which half is never expressed and quarters or specific sections cannot be; there is no graphical section rendering, and the item Type "Pizza" is documented "NO LONGER USED". https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
The Admin Portal guide documents "Recalled Border: Color of the border surrounding orders that have been recalled" on the Kitchen View (unbump), plus "Reprint Previous Items Sent: Reprints items that were previously sent to the kitchen on chits for orders that items were later added to" and a dedicated Kitchen Order reprint function — recall and refire/reprint without re-entering the order. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator
kitchen-order-modification-alerts
The Admin Portal guide's Kitchen View format options document "Edited Items: Color of order items that have been edited after being sent to the kitchen" and "Editing Items: Color of order items that are in the process of being edited after being sent to the kitchen," plus a separate "Modified Item Indicator: Symbol that will be printed on kitchen chits and displayed on kitchen displays for items that have been modified." https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
The PAR POS Order Ready Board Configuration Guide (Version 01, April 2026) documents it end to end: "A new customer-facing display, the Order Ready Board, has been introduced for installation inside the store, near the front counter. This screen provides real-time order status updates to guests, eliminating the need for staff to manually communicate order progress. Each order displayed on the board includes the order number, guest name, and order destination." The bump trigger is explicit: "IncludedKitchenQueueIds - The kitchen queue ID(s) that the ORB monitors to determine when an order is complete. When the specified queue is bumped, the order automatically moves from In Progress to Now Serving. Example: The Front Counter Expo is typically the last screen to be bumped, signaling that the order is bagged and ready for the customer." Statuses are "In Progress - the order has been received and is currently being prepared by the kitchen" and "Now Serving - the order has been completed, bagged, and is ready for guest pickup". Supported order types are in-store register, self-service kiosk, digital ordering platforms and third-party delivery applications. It is configured with PAR POS's own appsettings.json and ORBUIConfiguration.json files and communicates with the Primary Register over MQTT; no separate product purchase is named, though it needs a dedicated display. SMS is available only via a third-party provider account (Integration Settings Portal > Third-Party SMS Provider Configuration: EZ Texting, Plivo). https://cdn.parpos.com/docs/Order%20Ready%20Board%20Config%20Guide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Waste can be captured with a reason code, but not where the claim asks. The 5.16r2 Admin Portal Config Guide ships "Waste" as one of five Void Reason names (with 86'd Item, Kitchen Error, Server Error, Test Order), and Settings.svc confirms these are first-class configurable objects - GetVoidReasons returns a VoidReason type (Id, Name) - so an operator can log a waste void against an order with a reason code. Two shortfalls: the entry is made at the register void flow (and by End-of-Day auto-void of abandoned orders), not "directly at the kitchen/KDS screen" - Kitchen.svc has only two read-only bump-time operations and the KDS configuration types carry no logging action; and it depletes nothing, because Brink holds no inventory model (the Settings2 Items type has Cost but no on-hand or stock object anywhere in the 264-type schema). Structured waste logging with inventory debit requires PAR OPS's separate Store Waste Templates, a different product a Brink customer buys alongside. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
Kitchen SOAP service exposes queue and bump times consumable via API; PAR sells a drive-thru timer. No documented canned percentile SOS report sliced by daypart/station/channel. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01
Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.
kitchen-prep-forecasting
PAR OPS Forecasting predicts demand and PAR OPS includes prep label printing and checklists; a generated prep-quantity task list is not explicitly documented. https://partech.com/solutions/back-office-solutions/restaurant-forecasting-software/ · retrieved 2026-08-01
Delivery, dispatch & third-party channels
Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).
delivery-driver-roster
Drivers are first-class in PAR POS/Brink: the Jobs page has a 'Delivery' section with 'Delivery Driver: Displays the employee as the order recipient in the "Assign Delivery Order" screen' and 'Delivery Dispatcher: Allows the employee to execute "Assign Delivery Order" button behavior'; the Assign Delivery Order behavior states 'only employees clocked in under a job marked as delivery driver will appear' (so driver availability derives from real clock-in state) and 'Assigning an order to a delivery driver transfers ownership of non-cash payments to the driver'; Security Levels carry 'Can Close Orders Assigned to Delivery Drivers'. The Settings2 API exposes the same as Job.IsDeliveryDriver / Job.IsDeliveryDispatcher. SHORTFALL: no assignment state model beyond assigned/not-assigned - nothing documents an in-store / on-run / returning status - and the Admin Portal report catalogue (Accounting, Audits, Comparative, Configuration, Employees, Future Orders, Kitchen, Labor, Loyalty, Marketing, Orders, Product Mix, Sales by Brand / Day Part / Details / Summaries) contains no delivery or per-driver run-history report; the only Orders report is 'Order List by Destination'. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).
delivery-dispatch-board
Register button behavior 'Assign Delivery Order' - 'Opens "Assign Delivery Order" screen, which allows for assigning delivery orders to delivery drivers. Only orders with a destination marked as delivery will appear, and only employees clocked in under a job marked as delivery driver will appear. Current employee must be logged in under a job with "Delivery Dispatcher" enabled.' That is a dedicated dispatch screen with an undispatched-order queue and live driver availability. SHORTFALL: the behavior's Configuration Parameters column reads 'None' and the guide describes no elapsed-time-per-order column and no multi-order run batching (assigning 2+ orders to one driver as a single run); order-age styling in this product is a Kitchen Queue threshold feature (Color / Seconds / Flash / Mode) attached to kitchen displays, not to the dispatch screen. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator
delivery-route-map
The map half is documented and the turn-order half is not. PAR Ordering's Dispatch 2.0 "consolidates all the delivery Orders in one view, both as text and visually displaying them on the map", and names its geospatial suppliers - "Google Maps ODRD" and "HERE Tour Planning". Multi-stop runs are a first-class object: auto-assignment "will group Orders with the closest expected Delivery time and closest location to be delivered by the same Driver in a Route", and "The inactive (not started) Routes will be recalculated every time the new Order comes in or when Driver status changes" (https://supportcenter.partech.com/s/article/how-to-configure-and-enable-auto-assignment). Shortfall: sequencing within a route is the USER's, not the system's, and the support centre's four route articles are unanimous on it - "Here they can change the Order sequence of the Route" (how-to-edit-routes), "The sequence of Orders is saved as Draft - a sequenced list of Orders" (how-to-work-with-route-drafts), plus how-to-unassign-routes and creating-and-assigning-routes-to-drivers-or-dsp, none of which mentions optimisation. The manual path puts the sequence in the dispatcher's hands - "The User will have a possibility to create the Route by clicking the Orders in the delivery sequence desired" (https://supportcenter.partech.com/s/article/creating-and-assigning-routes-to-drivers-or-dsp) - and the automatic path is documented as grouping by proximity and expected delivery time, plus vehicle type and bag capacity, never as optimizing turn order. HERE Tour Planning is a route-optimization service and its presence is suggestive, but PAR states only that it is a party involved. Second shortfall: this is the PAR Ordering Dispatch module, separately licensed and "market-specific and Customer-specific" in price, not a Brink POS screen - Brink's own Assign Delivery Order screen remains documented as having no configuration parameters. https://supportcenter.partech.com/s/article/dispatch-2-0-overview · retrieved 2026-09-12 adversarially verified
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
PAR does ship a driver-facing mobile app that reports GPS position to the dispatch service, and it is documented in a help centre the 2026-08-08 pass never reached (supportcenter.partech.com, a Salesforce Experience site whose 1,109 articles are listed in /s/sitemap.xml). The Driver App 2.0 article states the app's location permission is mandatory - "the app will request permissions to access User location, notifications and activity tracking" - and publishes the reporting cadence: "While the Driver is online the application sends location updates to dispatching service every 3 minutes when the Driver does not move and every 30 seconds when the Driver moves". Loss of the feed changes dispatch state: "If the application has not been sending the location updates for more than 10 minutes - the Driver is automatically switched to offline". That settles the capture half of the claim. Shortfall, and it is the second half: no PAR document shows the captured position on the dispatcher's screen. Dispatch 2.0 does have a map, but what it plots is ORDERS - it "consolidates all the delivery Orders in one view, both as text and visually displaying them on the map" - and the map screen in the Driver App is the driver's own. Every delivery article in the support centre was read for this (dispatch-2-0-overview, dispatch-performance-dashboard, how-to-dispatch-orders-to-drivers, how-to-configure-and-enable-auto-assignment, creating-and-assigning-routes-to-drivers-or-dsp, how-to-edit-routes, how-to-unassign-routes, how-to-work-with-route-drafts, how-to-manage-driver-app, driver-app-2-0) and not one describes a driver pin, a fleet map or a driver-location column; the only PAR sentence about surfacing driver location points at the guest instead ("share the Driver location with your Clients in both setups"), and it sits in that article's competitive-positioning section. Second shortfall: this is PAR Ordering's Dispatch module, not a PAR POS / Brink module - "Dispatch is a PAR Ordering module that offers Order Delivery from various Channels" - it requires a Delivery Hub to be configured, and PAR states "Pricing: it's both market-specific and Customer-specific", so the capability depends on licensing a second PAR product. The Brink POS configuration surface itself still carries only the Assign Delivery Order screen and delivery-zone polygons, with no driver position field. https://supportcenter.partech.com/s/article/driver-app-2-0 · retrieved 2026-09-12 adversarially verified
Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator
delivery-zones-polygon
Settings2 documents DestinationDeliveryZone with a "Coordinates" field (alongside Name and SurchargeId) — a polygon/coordinate-defined delivery area, not solely a radius or ZIP/postcode list. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-04 adversarially verified
Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.
delivery-zone-pricing
Settings2 documents DestinationDeliveryZone (Name, Coordinates, SurchargeId "ID of the surcharge") and Destination fields LimitByDeliveryZone ("True if delivery address is to be limited to specific zones") and ValidDeliveryZones — polygon zones with a per-zone fee attached via surcharge and address limiting. Shortfall: no per-zone order minimum and no per-zone quoted promise time field is documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03
Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.
delivery-address-validation
Settings2 documents Destination fields "LimitByDeliveryZone: True if delivery address is to be limited to specific zones" and "ValidDeliveryZones," gating orders to configured delivery-zone polygons. Shortfall: no documented geocoding provider or address-level validation/rejection message at order time — only zone-membership limiting is described. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-04 adversarially verified
Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator
delivery-driver-comp
Two of the three inputs are documented. Driver-retained tips: assigning an order to a driver 'transfers ownership of non-cash payments to the driver', and jobs can be set to 'Must Declare Tips: Prompts employee for declared tips amount at clock out' with an optional 'Require Reporting of Minimum System-Calculated Tips'. Reimbursement-vs-wage split on export: the PAR OPS Delaget Connect API time_card object (api.delaget.com/swagger/v1/swagger.json) carries 'reimbursements' (type + amount) as its own collection alongside pay_rate, regular_hours, overtime_hours, charged_tips and tips, so reimbursements export as lines separate from wages. SHORTFALL: mileage or distance driven is not captured anywhere - zero occurrences of mileage or distance across the 290-page Admin Portal guide, the 659 anchors of brinkapiportal.parpos.com and the Delaget schema set - and the reimbursement field is a generic timecard line rather than a per-delivery flat reimbursement tied to a run, so per-delivery compensation must be derived outside the product. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.
delivery-cash-reconcile
The pieces of a driver settle-up exist as the generic self-banking flow. Job option 'Self Banking: Employee cannot be assigned a cash drawer - instead a personal till is automatically created for the employee'. Register behaviors: 'Start Bank: Assigns a new self-banking till to the current employee'; 'Checkout: Checks out the till assigned to the current employee' with parameters 'Type: Self-banking Employee or cash Drawer', 'Confirm Checkout', 'Print Report (checkout report)'; 'Edit Checkout: Prompts employee to select a previously checked out till to re-enter the declared cash'; 'Clock Out: Clocks out the current employees, and forces checkout if a till is assigned to the employee'; 'Undo Checkout'. Reporting: the Accounting report 'Till History' 'Lists till details for all checked out cash drawers and self-banking tills, sorted by checkout time'. SHORTFALL: none of this is delivery-aware - the guide documents no driver bank that nets cash collected against the orders assigned to that driver and the tips owed, and no per-driver over/short figure appears in the enumerated report catalogue. The only delivery-specific money behavior is that assignment 'transfers ownership of non-cash payments to the driver'. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.
delivery-daas-dispatch
Enumeration of the exposed order surface. The Order type on brinkapiportal.parpos.com is fully field-listed - Balance, BusinessDate, CreatedTime, CustomerId, DestinationId, Discounts, Entries, FutureOrder, Id, IdEncoded, IsClosed, IsSent, IsTaxExempt, LaneId, Name, Number, Payments, Promotions, Rounding, SectionId, Subtotal, Surcharges, Tax, Taxes, Total - with no courier, quote, ETA, driver or delivery-status field, so a courier quote and status have nowhere to return into the order record. The delivery payload on a new order is NewDeliveryDetails, which is address only (Address, Address2, City, Country, PostalCode, StateCode). The complete Ordering operation list is ApplyPayment, CalculateOrder, CancelOrder, GetItemAvailability, GetMasterTerminalStatus, GetOrder, GetParty, GetUnavailableItems, SendKitchenInstructions, SendOrder, SubmitOrder, UpdateItemAvailability - none dispatches to a courier. The register button-behavior table in the 5.16r2 Admin Portal guide, which is the entire configurable register surface, has exactly one delivery behavior, 'Assign Delivery Order', and it assigns to in-house drivers. PAR's own delivery product page describes 'Connect instantly to DoorDash, Uber Eats, and Grubhub platforms', '24/7 automated dispute detection' and 'Delivery reconciliation' - marketplace order ingestion and reconciliation, not DaaS courier dispatch of a first-party order. Reference is the legacy PAR POS API Portal, still fully served. https://brinkapiportal.parpos.com/sales2#OrderTypeTable · retrieved 2026-08-08
Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator
delivery-daas-fallback
Follows from the enumerated order surface (see delivery-daas-dispatch): the Order type carries no courier, quote or delivery-status field and no Ordering operation dispatches to a courier, so there is nothing for an overflow rule to target. On the in-house side the only documented assignment mechanism is the manual 'Assign Delivery Order' register behavior, whose Configuration Parameters column reads 'None'; the 5.16r2 Admin Portal guide documents no auto-assign, no wait-threshold escalation and no out-of-zone rerouting. The only zone rule is 'Limit by Delivery Zones: Limit delivery address to specific delivery zones', which blocks an out-of-zone delivery address rather than rerouting the order, and the only threshold rule engines in the product (Prep Times, Lead Times, Kitchen Queue thresholds) act on quote time and kitchen display styling. NOTE: this verdict shares its premise with delivery-daas-dispatch - if PAR ships courier dispatch through an undocumented partner path, both fall together. https://brinkapiportal.parpos.com/sales2#OrderTypeTable · retrieved 2026-08-08
Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator
delivery-3p-direct-integration
DoorDash direct integration is certified (2026 DPIP). PAR OPS claims instant connection to DoorDash, Uber Eats and Grubhub, but that page describes reconciliation/dispute data, not necessarily first-party order integrations for all three. https://partech.com/solutions/insights-and-delivery-solutions/ · retrieved 2026-08-01
Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.
delivery-3p-injection
DPIP eligibility requires a POS proactive cancel rate below 1% and merchant-avoidable cancellation rate below 1% on 250+ live stores — only achievable with automatic POS injection. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01
Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).
delivery-86-sync
Verified independently: "86 items" and "Item Polling" are both on DoorDash's mandatory capability list, with rolling 28-day enforcement (order failure rate and merchant cancel rate each below 1%, 250+ DoorDash stores to qualify as Established), and PAR holds 2026 PIP status. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01 adversarially verified
Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.
delivery-store-pause
Self-guided store setup and self-serve store activation are DPIP requirements; timed auto-reactivation driven from inside the POS is not documented. https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/ · retrieved 2026-08-01
Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator
delivery-3p-reconciliation
Downgraded on verification. Named shortfall: reconciliation is delivered by PAR OPS Delivery Operations (and disputes by the separate PAR OPS Recovery module), not by the POS, and covers only the three DSPs the page names - "Connect instantly to DoorDash, Uber Eats, and Grubhub platforms". The page says only that it "simplifies reconciliation and operations for all your delivery service providers" and never states what is matched against what. No product documentation exists: delaget.com now 302s to partech.com/delaget/, a placeholder offering only a client login and parops.support@partech.com, and the one primary artifact PAR publishes for this product line - the Delaget Connect API OpenAPI 3.0.4 spec at api.delaget.com - contains no delivery, DSP, DoorDash, Uber or Grubhub surface at all (its nine paths are organizations, workers, retail_transactions, location summary, time_cards, shift_diff and two diagnostics). https://partech.com/solutions/insights-and-delivery-solutions/ · retrieved 2026-08-02 adversarially verified
Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator
delivery-injection-error-visibility
Detailed order error reporting is a mandatory DPIP capability, and DoorDash's 2026 program gives merchants visibility into integration performance. A PAR-side operator alerting console for failed injections is not documented. https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026 · retrieved 2026-08-01
Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.
delivery-tracking-page
Guest-facing driver location is claimed, first-party, and the delivery surface for it is not documented. PAR Ordering's Dispatch 2.0 overview says the module lets an operator "share the Driver location with your Clients in both setups" - own fleet and DSP - and "provide the Clients with accurate estimates before they place the Order". Graded C rather than B because both sentences sit in the article's "Why is it unique?" positioning section, which compares PAR to competitors, rather than in a configuration procedure. What the guest receives IS documented, in a configuration article rather than that positioning section, and it is not a tracking page: the Catering Delivery Dispatch Module sends the customer email "notifications when a driver is assigned, when the order is picked up, and when it is delivered", and those emails "include a delivery-status progress bar and customizable title and description fields for each notification scenario" (https://supportcenter.partech.com/s/article/Catering-Delivery-Dispatch-Module). Shortfall: that is status email driven by real driver state, not a branded status page, not a tracking link, and not live driver location - the SMS in that module goes to the DRIVER, not the guest ("your brand's first-party delivery drivers receive a text message"), and no article states any guest surface is served on the restaurant's own domain rather than inside PAR's app. The only guest-location feature with a real procedure runs the other way: Trip Tracking / Smart Orders tracks the guest's approach to the store to time the fire (https://supportcenter.partech.com/s/article/trip-tracking-smart-orders). On the Brink POS side the guest-communication settings remain the Future Orders reminder email, the order-cancellation page link in the confirmation email footer, and the Pager-or-SMS party contact method, none of which is a tracking link. https://supportcenter.partech.com/s/article/Catering-Delivery-Dispatch-Module · retrieved 2026-09-12 adversarially verified
Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator
delivery-promise-time
The complete quote-time surface is enumerated in the 5.16r2 Admin Portal guide and contains none of the three named dynamics. Options > Future Orders > Prep Times: 'Minimum Prep Time: Default minimum prep minutes to be used for all future orders' plus Prep Time Rules whose Type is exactly one of 'Item Count', 'Order Amount', 'Contains Item', 'Contains Item In Group'. Options > Future Orders > Lead Times: 'Minimum Lead Time' plus Lead Time Rules with the identical four types, and 'Prep time is calculated as the Minimum Lead Minutes, or the highest Lead Minutes on all matching rules.' The delivery component is an explicit constant: Destinations > Delivery tab, 'Delivery Time: Average delivery time in minutes, used to calculate approximate delivery driver arrival time' - Settings2 exposes it as Destination.DeliveryMinutes (byte?). So the quote varies with what is on the order and never with current kitchen load, driver availability or zone drive time; delivery zones carry Latitude/Longitude coordinates and a SurchargeId but no drive-time attribute, and the API's LeadTimeThreshold and PrepTimeThreshold types carry a single LeadMinutes / PrepMinutes integer each. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
PAR now documents one limb of this explicitly, in the negative, and says nothing about the other two. Dispatch 2.0's conditions of use state "The product requires stable internet connection and Google Chrome browser", and require of the operator's own fleet "the drivers to have smartphones running on iOS or Android platforms with a stable internet connection". The Driver App documents the consequence of losing the link rather than a degraded mode: "If the application has not been sending the location updates for more than 10 minutes - the Driver is automatically switched to offline", and a driver who is offline stops receiving orders (https://supportcenter.partech.com/s/article/driver-app-2-0). So driver assignment during an outage is answered: it stops. Shortfall: cash delivery orders and driver settlement are still unaddressed. Neither the dispatch articles nor Brink's own offline documentation - the In-Store Resilience notes, the Show Offline Indicator register option, Force Authorization for offline credit authorizations, Accept Orders when Primary is Offline - says whether a driver till checkout or driver settlement can be completed while the store is offline, and PAR's offline documentation is organised by subsystem (ordering, payment, kitchen) with no delivery section. https://supportcenter.partech.com/s/article/dispatch-2-0-overview · retrieved 2026-09-12 adversarially verified
Digital ordering & guest-facing channels
Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.
digital-first-party-web
PAR Ordering provides first-party branded web ordering; commission model not published. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
Citation re-pointed 2026-08-09 after the old developers.partech.com slug 301'd; quotation re-verified at the destination. The Punchh Mobile API reference states the APIs execute loyalty programs "primarily via business-branded mobile apps and websites tailored by Punchh" - PAR's own documentation asserting it produces the branded app, not merely APIs a brand could build one against. The documented endpoint groups are a complete consumer-app surface: Users (login, social login via Facebook/Google/Apple, profile, password reset), Payment Cards, Payments, Offers, Coupons, Collectibles, Challenges, Check-ins, Badges, Beacons, Drive-Thru, Gift Cards, Locations, Notifications, Redemptions 2.0, Referrals, Loyalty Transfers, Surveys, Single Scan Code, Swag, WiFi Acquisition. Not documented: any native iOS/Android SDK. https://developers.partech.com/docs/dev-portal-mobile/apis/mobile-api · retrieved 2026-08-09 adversarially verified
Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.
digital-account-saved-payment
Citation re-pointed and strengthened 2026-08-09. The Punchh Mobile API - PAR's documented surface for business-branded guest apps and websites - documents a Users group with signup/login (including Facebook, Google and Apple sign-in), profile and account_history, and a Payment Cards group whose operations are explicitly "Fetch All Saved Payment Cards" (GET /api2/mobile/payment_cards), "Create a Payment Card" (POST), "Update a Saved Payment Card" (PUT /{payment_card_uuid}) and "Delete a Saved Payment Card" (DELETE), alongside a Payments group. Guest accounts with saved, tokenized payment methods are therefore documented rather than inferred. Shortfalls: there is no addresses endpoint or address-book group anywhere in the Mobile API reference (the guest record carries only a single profile address_line1/city/state/zip), and no reorder or order-history endpoint - one-tap reorder of a previous order is not documented. https://developers.partech.com/docs/dev-portal-mobile/apis/mobile-api/tag/payment-cards · retrieved 2026-08-09 adversarially verified
Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator
digital-upsell-engine
AI-powered upsells and cart reminders claimed; attach-rate reporting on those suggestions not documented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01
Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.
digital-scheduled-pacing
Scheduled orders supported; per-daypart capacity throttling that auto-closes slots is not documented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01
Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.
digital-fulfillment-modes
Pickup, QR table ordering, delivery, kiosk and catering named. Curbside with arrival check-in not named. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01
Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.
digital-qr-table
The in-store guest-scan pieces are documented. Options > Online Ordering > General: 'In-Store Menu: Menu to be displayed on Customer Portal mobile when in in-store ordering mode'; a dedicated 'Mobile In Store Destinations' tab ('allows you to specify which destination or destinations a mobile in-store order can be processed under') and an 'In Store Alternate Menus' tab. Tipping is supported on the same channel: 'Allow Tips: Customers ordering online will be prompted to add a tip to their order' plus three configurable 'Suggested Tip' percentages. The scan vector is configurable: Receipt Footer 'Show QR Code: Prints QR code at bottom of receipt' with a free-form 'URL: URL to be embedded in QR code (must be valid URL)' and 'Always Print'. Scan-to-pay exists through the loyalty partner: 'For Punchh Single Scan Payment to work on the POS, the location must be configured with Punchh Loyalty and Punchh External Payment. Note: The Punchh application must also be enabled for QR code payment.' SHORTFALL: nothing documents a scan opening or attaching to an existing open POS check, and no guest-side check splitting is documented - a mobile in-store order is a new order under an in-store destination, and Split Check is a register behavior gated on a staff security level. Native pay-at-table is a payment terminal rather than a QR flow: Settings2 PayAtTableOptions is PayAtTableType (None | ParPay), PortNumber ('Port the payment device is connected to') and PromptForTip. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator
digital-kiosk
First-party kiosk with loyalty identification, points, redemption and payment in one scan (Loyalty Pay); no published accessibility conformance. https://partech.com/solutions/guest-engagement-platform/digital-experience/ · retrieved 2026-08-01
Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.
digital-group-ordering
The ordering contract has no multi-participant concept. PAR's guest-ordering surface is published as two OpenAPI documents — the Ordering API (83 operations) and Cart 2.0 (8 operations: POST /cart/init, GET/PUT /cart/{cart_id}, POST /cart/{cart_id}/checkout, /payments/init, /order, and POST /cart/reorder/validate and /cart/reorder) — and across both operation sets a cart belongs to one customer account: there is no invite, join, share, participant, sub-cart or per-person cap operation, and no split-tender checkout. Absence control: 'shareable link', 'spend cap', 'split payment' and 'split the bill' each occur ZERO times across all 1,358 documents; 'group order' matched 7 documents and ALL SEVEN are the sidebar navigation widget rendering 'Open Group'/'Close Group' immediately before 'Order Lifecycle' or 'Order Management' — a layout artefact, not the feature. Limit stated plainly: The spec is a floor for prose: of the 28 OpenAPI documents only par-pay's declares `additionalProperties: false` (99 times); the other 27 declare it zero times, so no schema ceiling exists. An operation list is nonetheless a complete enumeration of the API's operations, which is what this claim turns on. https://developers.partech.com/docs/ordering-api/guides/apis/cart-2-0 · retrieved 2026-09-09 automated extraction
Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator
digital-catering-portal
Catering order management named; separate minimums, lead-time rules, quotes, deposits and invoice/ACH terms not documented. https://partech.com/solutions/guest-engagement-platform/online-ordering/ · retrieved 2026-08-01
Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator
digital-voice-ai-phone
CLAIM: AI voice phone ordering (native or named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. VERDICT: partial/B. EVIDENCE: PAR Ordering release notes "March Release - v4.72" (first published 2026-03-26, article 000002559) list "AI Phone Ordering" under "What's new?" and say: "Integrated with SunDevs to enable AI-powered phone ordering, expanding ordering channels and automation capabilities." (https://supportcenter.partech.com/s/article/March-Release---v4-72-0). PAR's roster "Where can I find a list of the current PAR Strategic Partners / API Integrators?" also names "Converse Now" under "Voice AI" (https://supportcenter.partech.com/s/article/where-can-i-find-a-list-of-the-current-par-strategic-partners-api-integrato). The 2026-09-12 pass left this unknown because the roster states no channel; the release note now names the PHONE channel and a partner in a first-party document. SHORTFALLS: (1) it is a PAR Ordering integration, not a PAR POS/Brink module (the same shortfall the delivery-route-map cell carries); PAR Ordering does inject orders into the POS ("POS Order Injection is the process of sending customer orders from our platform to your store's POS system", https://supportcenter.partech.com/s/article/How-to-Configure-POS-Order-Injection-for-Future-Orders), but no page says SunDevs phone orders take that path; (2) nothing states the agent answers inbound calls unaided or that no staff transcription happens. A one-line release note does not carry every conjunct, so not yes. New surface: full anonymous Salesforce Aura census of supportcenter.partech.com (Knowledge__kav.Customer_Facing_Answer__c + Title; sitemap-topicarticle-1.xml 1,103 slugs + href fixpoint = 1,109 slugs probed, 1,102 bodies held, 5.6M chars; 7 unresolved, 6 of them hrefs copied from other vendors' KBs). Most of the corpus documents PAR Ordering (formerly MENU; Management Center/CMS), a sibling product that injects orders into PAR POS (Brink); only 31 bodies say Brink. Retrieved 2026-09-16. https://supportcenter.partech.com/s/article/March-Release---v4-72-0 · retrieved 2026-09-16 adversarially verified
Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.
digital-drivethru-ai
Assessed 2026-08-08. PAR's documented drive-thru surface is conventional. The 5.16r2 Admin Portal Config Guide covers drive-thru lanes (Job.LaneId, Options > Future Orders 'Default Lane: Lane in which future orders are to be added'), order channels 'Delivery, Drive-Thru, etc.' selectable per promotion and per price change, a 'Vehicle ID Panel' register behavior, and 'Use Paid Order Sequencing: Applies order sequencing to drive-thru orders based on order payment' (annotated 'No longer supported as of the 5.0m Release'). Nothing in that 290-page guide, in the 659 anchors on brinkapiportal.parpos.com, or on developers.partech.com describes AI voice ordering at the lane, menu/modifier grounding for a voice agent, or an escalation-to-human handoff. partech.com/integrations/ renders its category filter client-side so no voice-AI category could be enumerated, and an integration directory would not be enumeration evidence regardless. Unresolved rather than absent. Re-examined 2026-09-12 against PAR's drive-thru product documentation, which is published after all: the PAR DT Portal User Guide v2.3 (July 2026, support.partech.com, 1,229 extracted lines) documents the whole PAR Drive-Thru Cloud Management Portal - devices, store and lane layout, stacking spaces, merge points, parking area, dashboard and leaderboard layout, goals, vehicle settings, messages, events and queues, firmware update, and a report builder. Tokenised, `voice`, `ai`, `agent`, `escalation`, `escalate`, `conversational` and `speech` each occur zero times across its 11,062 tokens, while `lane`, `vehicle`, `timer` and `report` all fire, so the matcher is sound. That is NOT scored as absence, because the guide's own Intended Use section bounds the product to metrics: the system is "intended for use to provide the user with a monitor display view of their current drive thru car lane status along with data and metrics", so a lane voice agent would not live in this portal and its silence is not about ordering. PAR's support centre roster does name one Voice AI integrator (Converse Now) without stating the channel. Unresolved. || 319th: NEW (not moved). NEW SURFACE: product-docs.partech.com (Scalar docs; robots Allow: /; llms.txt 156,164 bytes lists 546 URLs = sitemap.xml 546 <loc>; par-pos section 164 URLs, 163 fetched as markdown via the .md suffix at 200, 1 slug (ingenico Move 5000 Canada) mangled by my extractor; the rest are Punchh 374 and Guest360 7). Found via crt.sh %.partech.com (301 names). Settings Editor > Options > Drive Thru has two sub-tabs only, "Vehicle Color Panel and Vehicle Type Panel", used "in tandem with Automatic Order Sequencing". Across the 163 PAR POS pages "voice" occurs 3 times, all POISON (the offline credit "Voice" authorization button), and "AI" only as the AVA Beta admin chatbot, AI Upsell (cashier recommendations for Punchh guests) and screenshot alt text. crt.sh %.partech.com also surfaced PAR drive-thru hosts: portal.drivethru.partech.com ("DT Cloud Portal - Partech"; index-lj2mYU5f.js 578,638 bytes and App-Cyge_gc8.js 2,609,838 bytes read anonymously) has no voice/speech/order-taking string (its one "voice" is an Auth0 MFA oobChannel, POISON); api.drivethru.partech.com 404s at root; drivethru.partech.com NXDOMAIN. Absence of evidence only: partner-delivered voice AI would not appear on these surfaces. Retrieved 2026-09-16. || 323rd: NEW (323rd): NEW SURFACE (323rd): the LABEL DICTIONARY of the production Brink Integration Settings Portal - https://prod.integrations.parpos.com/assets/i18n/en.json, fetched anonymously 2026-09-17, HTTP 200, content-type application/json, 21,316 B, body opens {"ENTITY":{"COMPCARD":{...}. The 319th held this app's minified bundle (main.c1e78e4876a8ad7a.js, 1,795,497 B, re-fetched byte-identical today) but not this file, which renders every field name the portal shows. SOFT-200 CONTROL: on this host /assets/config.json, /assets/i18n/en-US.json, /main.c1e78e4876a8ad7a.js.map and /zzz-nope.js.map ALL return the 49,476-byte Angular index.html shell as text/html, so there are no source maps here and the en.json 200 counts only because it differs in length, type and first bytes. The dictionary's ENTITY key is a closed list of the 13 integration types the portal configures: COMPCARD, CONTACTLESSPAYMENT, CREDITCARDOPTIONS, CREDITPROCESSOR, EXTERNALKITCHEN, EXTERNALPAYMENT, GIFTCARDOPTIONS, GIFTPROCESSOR, LOYALTY, ORDERSTATUSEVENT, PAYMENTDEVICE, PERIPHERAL, SMS. If Brink had a lane voice-AI partner it would be configured as an integration entity, and the closed 13-entity list contains none: the nearest is ENTITY.EXTERNALKITCHEN ("EXTERNALKITCHENTYPE": "Type", "IPADDRESS", "IPPORT", "ONTHEFLYENABLED": "On The Fly") and ENTITY.ORDERSTATUSEVENT (an endpoint/verb/format webhook). TOKENISED CONTROLS over both artefacts: `voice` 0 in the dictionary and 0 in the 1,795,497-byte bundle; `kiosk` 0 / 2; `ai ` 0 / 0; POISON: `drive` matches 32 times in the bundle and is Angular's animation `_driver` every time, and `thru` 8 times as lodash's chain helper (`la.prototype.thru`, `we.thru(ie)`) - neither is the drive-thru lane. BOUND: this is one production app (per-location integration configuration), not a census of Brink, so no `no` is published on it. Retrieved 2026-09-17. || 325th: NEW SURFACE (325th) AND A HOMONYM WORTH RECORDING. developers.partech.com censused properly for the first time: robots.txt is 'User-agent: * / Allow: /' and names the sitemap; sitemap.xml (HTTP 200, 92,094 bytes) lists 531 URLs -- 115 ordering-api, 84 dev-portal-webhooks-manager, 76 dev-portal-pos, 67 dev-portal-mobile, 63 dev-portal-online-ordering, 57 dev-portal-platform-functions, 32 dev-portal-developer-resources, 12 pos-next, 8 par-pay, 7 guest360 (sic, 6 identity-service), 4 parpos-cloud-apis, 2 eo-api and 4 product landing pages; llms.txt is 142,405 bytes. It is a Scalar site and the ReadMe-style `.md` suffix works on the PROSE pages (303 of the 531 fetched at 200) but not on the Stoplight-rendered API-reference pages (227 hard 404s, 1 HTTP 500 at the .md suffix; their HTML renders server-side and is fetchable without it). Tokenised controls over the 6,843,305-byte prose corpus (530 bodies): 'voice' 0, 'conversational' 0, 'text-to-order' 0, 'Order with Google' 0, 'Apple Business Connect' 0. THE HOMONYM: the 24 case-insensitive drive.?thru hits are NOT an AI lane. The substantive one is a PAR Ordering release note -- 'Drive-Thru: We're introducing a dedicated Drive-Thru order type within the PAR Ordering Ecosystem. With Drive-Thru, users can place their order through the web app or mobile app and pick it up at a designated drive-thru window with no need to leave their car' -- i.e. a guest-app order TYPE with window pickup, plus a Punchh mobile endpoint POST /api2/mobile/drivethru_code. No AI voice agent, no menu/modifier grounding, no escalation-to-human handoff anywhere in the 531 URLs. Still unresolved; a floor, not a census of PAR's marketing. Retrieved 2026-09-17. || 326th: MERGE HOLD (proposed no/C, held unknown): PAR's own support-centre partner enumeration has a Voice AI category containing ConverseNow, already this record's cite for the order-capture-voice-ai partial; ConverseNow sells drive-thru voice AI, so a partner-delivered lane cannot be excluded and a no is unsafe. PROPOSAL AS WRITTEN: 326th: MOVED to no. The one corpus every prior pass lacked was PAR's own marketing, and PAR markets drive-thru harder than almost anything else it sells, which makes its silence here evidential rather than merely absent. NEW SURFACE: anonymous WP REST census of partech.com (content types enumerated at /wp-json/wp/v2/types, then every public type paged to its x-wp-totalpages: pages 103, posts 224, resource-post 247, news-coverage 93, press-releases 56, testimonials 3, sub-processors 72 = 798 documents, 2,590,281 chars). `drive-thru` fires 525 times in 108 of the 798 documents, so the matcher is sound and the subject is heavily covered. What those 108 documents sell is CONVENTIONAL: PAR Clear, a drive-thru HEADSET (70 hits in 8 docs: 'crystal-clear audio quality and advanced voice isolation technology', 'Extended Range ... single-lane or dual-lane'), and the PAR DT Cloud Management Portal (timers, lanes, leaderboards). CONTROLS, tokenised, case-insensitive, over the 798: `conversenow` 0, `soundhound` 0, `presto` 0, `drive-thru ai` 1 hit and it is a 2022 trend blog describing PANERA's proprietary 'Tori', not a PAR product; `voice` 47 hits in 25 docs and the distribution is the poison - HR/ERG 'voice concerns', a privacy-policy 'video, voice and image' clause, PAR Clear headset audio ('voice isolation', 'subtle voice tones'), and industry trend pieces about Alexa/Siri. `voicify` 3 hits in exactly 1 document, a co-marketing webinar landing page ('PAR Technology joins Voicify, Solink, and ProLiant ... How AI-powered voice ordering captures every call and upsell opportunity') - that is PHONE call answering, third-party, and it names no lane, no menu/modifier grounding and no handoff. Same controls over product-docs.partech.com fetched to 100% of its 546-URL sitemap this pass (545 pages at 200, 4,942,116 chars): `voice` 3 hits, all poison (the Admin Portal 'Voice' offline-credit authorization right, two Punchh pages). Prior bounded corpora, unchanged: 531-URL developers.partech.com (6,843,305 chars, `voice` 0, `conversational` 0), the 1,102-body supportcenter.partech.com Aura census, the DT Cloud Portal's own anonymous bundles (index-lj2mYU5f.js + App-Cyge_gc8.js, only `voice` an Auth0 MFA channel), and the PAR DT Portal User Guide v2.3. DISCLOSED COUNTER-EVIDENCE, weigh it: PAR's support centre publishes a CATEGORISED partner enumeration, 'Where can I find a list of the current PAR Strategic Partners / API Integrators?', which does contain a category headed 'Voice AI' with exactly one member, 'Converse Now'. That entry is already what carries this vendor's order-capture-voice-ai at partial/B. It states no channel, no menu/modifier integration and no escalation-to-human handoff, and nothing in 798 marketing documents, 545 doc pages, 531 developer URLs or 1,102 support bodies places any voice agent in a PAR drive-thru lane. THIS IS MY WEAKEST PAR ROW: if the adjudicator reads the Voice AI partner category as sufficient for the lane, downgrade to unknown with this census recorded. Retrieved 2026-09-18. MERGE NOTE (326th): graded C, not B: the cited URL is the vendor marketing host; the product-docs and API corpora are supporting bounds. || 329th: MERGE HOLD (proposed partial/D, held unknown): The only evidence is a RETIRED partner-marketplace category (parpospartners.partech.com, NXDOMAIN today, Wayback 2024-12-10) listing three third parties' voice-AI products at grade D. A third party's product is not the vendor's feature (328th maitred/QSR precedent), and nothing states menu/modifier grounding or human handoff on Brink. PROPOSAL AS WRITTEN: 329th: MOVED unknown -> partial (weakest row of this pass; see the downgrade instruction at the end). NEW SURFACE, never mined by any prior pass: PAR's own Brink partner marketplace, parpospartners.partech.com ('PAR POS Integrated Partners', 'Become a PAR Brink POS Integration PARtner', PartnerFleet-hosted on PAR's own subdomain with PAR's nav and privacy policy). The host is NXDOMAIN today; recovered from Wayback CDX (54 URLs captured: 29 /partners/<slug> pages and 15 /t/brink-categories/<category> pages - digital-signage-slash-menu-board, gift-card, inventory, kiosk, labor, online-ordering, ordering/loyalty, other, payments, property-management, reporting, scheduling, video-slash-video-ai, voice-ai). The Brink 'Voice AI' POS category page (capture 2024-12-10, 636,216 B) says '1 - 3 of 3' and names exactly: 'Presto Automation Inc. - A leader in drive-thru voice automation', 'Clinc' and 'Lilac Labs (Speech Intelligence Inc)'. Presto's own partner page on the same PAR host reads 'Presto Phoenix, Inc. is the largest American drive-thru Voice AI provider to the restaurant industry. Presto's Voice AI product increases revenue, decreases labor costs, improves staff productivity, and enhances the guest experience' under 'POS Categories: Voice AI'. So PAR itself published a Brink-scoped Voice AI integration category whose members are drive-thru lane voice providers - which is why no `no` is safe here (the 326th hold stands and is now reinforced by three named partners rather than one). PARTIAL, with the shortfall named: only the first conjunct of the claim is satisfied (AI voice ordering at the drive-thru lane, via certified partners); the second and third are NOT - nothing states menu/modifier grounding for the voice agent and nothing states escalation-to-human handoff, and the capability is partner-delivered rather than native (PAR's own drive-thru products remain the PAR Clear headset and the DT Cloud Management Portal, whose Intended Use is 'a monitor display view of their current drive thru car lane status along with data and metrics'). GRADE D and RETIRED: this is a vendor-published partner-directory card, and the host no longer resolves, so under the retired-copy rule it may carry at most a partial. DOWNGRADE INSTRUCTION: if the adjudicator applies the 328th hold that a third party's product is not the vendor's feature, revert this cell to unknown and keep the marketplace census in the note - the census is the durable finding. Retrieved 2026-09-18. adversarially verified
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
326th: MOVED to no. Prior passes had the shipped configuration surface (ENTITY.SMS = six sender-credential fields, providers pinned in code to [EzTexting, Plivo]) and the support corpus, and held because 'inbound ordering would live in PAR Ordering or partners'. The marketing site is where PAR announces PAR Ordering features, and it is now censused. NEW SURFACE: anonymous WP REST census of partech.com - content types enumerated at /wp-json/wp/v2/types, then every public type paged to x-wp-totalpages: 798 documents (103 pages, 224 posts, 247 resource-post, 93 news-coverage, 56 press-releases, 3 testimonials, 72 sub-processors), 2,590,281 chars - plus product-docs.partech.com fetched to 100% of its 546-URL sitemap (545 pages at 200, 4,942,116 chars), which for the first time includes the 374 Punchh pages, i.e. the product that actually owns PAR's SMS channel. CONTROLS, tokenised, case-insensitive, over the 798 marketing documents: `text-to-order` 0, `text to order` 0, `scan to order` 0, `chat ordering` 1 hit and it is a 2024 industry-trends blog listing it as a sector prediction, not a PAR feature; `chatbot` 13 hits in 10 docs, all trend/AI-positioning copy plus the PAR Intelligence page, none an ordering channel. Over the 545 doc pages, `sms` fires 451 times in 67 files - the matcher is sound and SMS is well covered - and the consumers are all outbound: the Integration Settings Portal SMS provider form, Kitchen Queues 'Send SMS - Message: Content of the text message to be sent', CheckPlease 'Enable Text-to-Pay'/'SMS Template', order-status notifications, and Punchh SMS marketing campaigns. Not one inbound keyword, opt-in reply, conversation, cart or menu surface exists in any corpus. Five independent bounded corpora now (798 marketing documents, 545 doc pages, 531 developer URLs, 1,102 support bodies, the Integration Settings Portal's own 13-entity label dictionary) and PAR's SMS estate is entirely outbound: text-to-PAY and notification, never text-to-order. Retrieved 2026-09-18. MERGE NOTE (326th): graded C, not B: the cited URL is the vendor marketing host; the product-docs and API corpora are supporting bounds. https://partech.com/wp-json/wp/v2/pages?per_page=100 · retrieved 2026-09-18 adversarially verified
Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator
digital-google-order
326th: MOVED to no. The 320th's reason for holding was that product-docs is not a census (live pages link to withdrawn ones) - true, and unchanged - but the missing corpus was PAR's own marketing site, which is where a channel placement like this is announced. NEW SURFACE: anonymous WP REST census of partech.com, content types enumerated at /wp-json/wp/v2/types then every public type paged to x-wp-totalpages: 798 documents (103 pages, 224 posts, 247 resource-post, 93 news-coverage, 56 press-releases, 3 testimonials, 72 sub-processors), 2,590,281 chars. This is a census of the site's own content model, and PAR uses press-releases and news-coverage types heavily, so a channel launch would be in it. CONTROLS, tokenised, word-boundary, case-insensitive, over all 798: `order with google` 0, `google business profile` 0, `google business` 0. ALSO re-fetched product-docs.partech.com to 100% of its 546-URL sitemap for the first time (545 pages at HTTP 200, 4,942,116 chars - the 374 Punchh and 7 Guest360 pages had never been searched, only the 164 par-pos ones): `order with google` 0/545, `google business` 0/545. With the 531-URL developers.partech.com census (`Order with Google` 0) and the 1,102-body supportcenter.partech.com Aura census already on the record, that is four independent bounded corpora covering the POS, the developer platform, the support centre and the marketing site, and none of them provisions a PAR ordering link onto a Google Business Profile. Retrieved 2026-09-18. MERGE NOTE (326th): graded C, not B: the cited URL is the vendor marketing host; the product-docs and API corpora are supporting bounds. https://partech.com/wp-json/wp/v2/pages?per_page=100 · retrieved 2026-09-18 adversarially verified
Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.
digital-apple-business-connect
326th: MOVED to no on the same new bound as digital-google-order. NEW SURFACE: anonymous WP REST census of partech.com - content types enumerated at /wp-json/wp/v2/types, then every public type paged to x-wp-totalpages: 798 documents (103 pages, 224 posts, 247 resource-post, 93 news-coverage, 56 press-releases, 3 testimonials, 72 sub-processors), 2,590,281 chars - plus product-docs.partech.com fetched to 100% of its own 546-URL sitemap for the first time (545 pages at 200, 4,942,116 chars; the Punchh 374 and Guest360 7 sections had never been searched). CONTROLS, tokenised, case-insensitive: `apple business connect` 0 in all 798 marketing documents AND 0 in all 545 doc pages; `order food` never appears as a place-card action. DISCLOSED COUNTER-EVIDENCE, unchanged and still the only thing in PAR's estate that touches Apple Maps: PAR Ordering's SOCi listings integration, 'Store-level details like hours, address, and phone number now automatically sync with listings on Google, Facebook, Apple Maps, and more' - business-information sync, not an ordering action. Everything else Apple in the corpora is Apple Pay, Apple Wallet/VAS loyalty, Sign in with Apple, or the Integration Settings Portal's ISAPPLEVASENABLED payment-terminal field: all POISON for a place-card 'Order Food' action. Four independent bounded corpora (798 marketing documents, 545 doc pages, 531 developer URLs, 1,102 support bodies) and none documents, markets or announces an Apple Business Connect placement. Retrieved 2026-09-18. MERGE NOTE (326th): graded C, not B: the cited URL is the vendor marketing host; the product-docs and API corpora are supporting bounds. https://partech.com/wp-json/wp/v2/pages?per_page=100 · retrieved 2026-09-18 adversarially verified
Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.
digital-loyalty-attach
Punchh loyalty is integrated into PAR Ordering; Loyalty Pay lets a guest identify, earn, redeem and pay in a single scan at counter, kiosk or drive-thru. https://partech.com/solutions/guest-engagement-platform/digital-experience/ · retrieved 2026-08-01
Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.
digital-subscriptions
Punchh program design explicitly includes memberships; recurring-billing mechanics not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.
digital-promo-parity
Punchh integrates across POS, digital and mobile via open APIs so offers are defined centrally; explicit channel-eligibility controls not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator
digital-guest-data-ownership
Self-serve bulk export exists and is an Admin Portal function rather than a support request: 'The Export section provides tools for exporting customers, sales, labor, settings, and surveys.' 'Customers - The Export Customers tool produces a CSV file for download which contains customer records that match the selected filters', with filters for birthday, gender, 'Preferences: Filter the customers by one or more communication preferences' (the consented-marketing dimension), order date, items ordered, preferred location, signup location, signup date, 'Filter By Email Address: Filter customer to those whose email address is in a given list of email addresses' and 'Filter By Zip Code'. No fee, quota or approval step is mentioned anywhere in the Export section. SHORTFALL: PAR publishes no statement that the operator owns the guest records; the guide never enumerates the exported CSV's columns, so email and phone presence is inferred from the filter set rather than documented; and order history is not part of this export - 'The Export Sales tool produces a file that can be imported into a third-party accounting or inventory system', formatted from the Options > Accounting > GL Export mapping (QuickBooks IIF, for example), which is general-ledger data rather than per-guest order history. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.
digital-checkout-pci-sca
The hosted-fields half is documented. The PAR Pay Service API reference on PAR's unified developer portal exposes GET /creditcard/v1/iframeurl, documented as a hosted iFrame URL for secure card data entry, alongside /creditcard/v1/purchase, /preauth, /capture, /void, /refund, /creditcards (GET and PATCH) and /googlepayconfiguration, with OAuth via POST /oauth/token; card-on-file is a stored-instrument surface rather than a PAN surface. On the POS side, Brink's Ordering API accepts a NewOrderPayment of type NewExternallyTokenizedCreditCardPayment, so a digital channel can settle without the PAN entering the order payload, and the Admin Portal carries a group-level Tokenization page for third-party tokenization providers. SHORTFALL: no 3-D Secure endpoint, parameter or field appears anywhere in the PAR Pay reference, and PAR publishes no PCI DSS 4.0 statement at all - nothing addressing the client-side script-integrity requirements (6.4.3 and 11.6.1) effective March 2025 - on developers.partech.com, brinkapiportal.parpos.com or cdn.parpos.com/docs/. https://developers.partech.com/docs/par-pay/ · retrieved 2026-08-08
Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator
digital-surcharge-transparency
One engine, scoped to channels. Surcharges are configured once - 'Surcharges are additional fees that can be applied to an order and are excluded from reported sales' - with Surcharge Style = Gratuity, Service Charge, or 'Non-Cash Adjustment: Allows the restaurant to take the interchange fee which it has to give to the processors for a credit card payment from the guest. If the guest pays by cash, they do not have to pay the interchange fee. If the guest pays through credit card, the interchange fee is added to the bill amount' - dual pricing - and Method = Fixed Per Order, Fixed Per Item, Percentage Per Order, Percentage Per Item, with 'Automatically Apply' for qualifying orders. Digital parity comes from the 'Valid Destinations tab: When Limit Destinations is checked, the surcharge can only be applied to the selected destinations', and online orders run under destinations chosen in Options > Online Ordering > Destinations, so the same surcharge configuration governs the Customer Portal and the Ordering API; surcharges are also first-class in the API (Order.Surcharges, NewOrderSurcharge, GetSurcharges). SHORTFALL: the Edit Surcharge dialog's complete tab set is Party Size, Dates, Hours, Days, Valid Terminals, Valid Destinations, Valid Items, Valid Sections and Taxes - there is no guest-facing disclosure text field, no card-brand restriction (hence no way to suppress on brands that prohibit surcharging), and no state or jurisdiction control. Compliance is left entirely to the operator's own destination, terminal and section scoping. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Guest data, loyalty & marketing
Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.
guest-loyalty-unified-profile
Punchh integrates across POS, digital and mobile channels; PAR ships a Guest Identity Service in PAR Common Services on the developer portal. Documented dedup/merge behavior not published. https://developers.partech.com/ · retrieved 2026-08-01
Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator
guest-loyalty-thirdparty-identity-attach
PAR closed its acquisition of Bridg (identity resolution / shopper intelligence) on March 24, 2026, which is aimed at resolving otherwise-anonymous transactions. Marketplace-order attach specifically is not documented. https://partech.com/wp-content/uploads/2026/05/050726-PTC-Earnings-Release-Q1-2026-Final.pdf · retrieved 2026-08-01
Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.
guest-loyalty-accrual-models
Punchh supports visit-based programs, points that unlock rewards, points redeemed at a threshold, and banked currency — well past the two-model bar. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
Loyalty tiers explicitly supported and configurable; automatic rolling-window promotion AND demotion not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
Lookup and accrual are documented explicitly; redemption is not. POS API Certification Module 10 (Handling POS Disconnections) states the goal is to 'Handle the processing of transactions in a queue at the POS in the event of a network outage', that the POS 'is expected to queue all transactions and store them locally for a minimum of 10 days and a maximum of 30 days until the connectivity is restored', and that on restore 'the POS will begin to send the POS check details to the Punchh datasink in order of first-in, first-out (FIFO) until the queue is emptied'. That is queue-and-reconcile, named as such. Lookup is documented as blocked: Module 9 states the POS is 'unable to perform loyalty user look-up or check-in, and therefore loyalty users will not be able to earn', and the documented fallback is that 'the POS generates a unique barcode or QR code so the guest can earn points/visits although the POS is offline', which the guest scans in the mobile app to earn once connectivity returns. Shortfall: offline REDEMPTION behaviour is not addressed anywhere — the modules cover check queuing and deferred earning only, and no document states whether a reward can be redeemed, is blocked, or risks double redemption while the POS is disconnected. Note also the framing: this is a certification requirement written for POS integrators ('the POS should support'), i.e. the loyalty platform's contract, not a description of PAR POS's own implementation. https://developers.partech.com/docs/dev-portal-pos/tutorials/modules/10-handling-pos-disconnections · retrieved 2026-09-09 automated extraction
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
The Promotions type on the PAR POS API portal exposes stacking and precedence directly as configuration fields: 'AllowLaterOrderReductions - True if other promotions and discounts can be applied to orders that already have this promotion applied'; 'AllowPriorOrderReductions - True if this promotion can be applied to orders that already have a promotion or discount applied'; 'AllowPriorItemPromotions - True if this promotion can be applied to items that already have a promotion applied'; 'AllowPriorModifierPromotions - True if this promotion can be applied to modifiers that already have a promotion applied'. That is exclusive-versus-combinable in both directions and at order, item and modifier scope. Order of application is 'Priority (ushort) - Sort priority of this Promotion'. Volume is capped by 'MaximumPerOrder - Maximum number of times the promotion can be applied to a single order' with 'EnforceMaximumPerOrder', and value by MaximumAmount with EnforceMaximumAmount. This is the engine third-party loyalty rewards land in: the 5.16r2 Admin Portal Config Guide defines 'Loyalty Discount: Discount can only be applied via the redemption of a loyalty reward' and 'External ID: External identifier for mapping to loyalty rewards in external loyalty providers', so a provider's rewards are subject to the same stacking and precedence rules. Reference is the legacy PAR POS API Portal, which still serves full content. https://brinkapiportal.parpos.com/settings2#PromotionsTypeTable · retrieved 2026-08-08
Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator
guest-loyalty-targeted-offers
Upheld, evidence replaced with the API reference. The Custom Segment APIs document nine operations - list, create, update and delete a custom segment, plus add, remove, search, bulk-add and bulk-remove guests within one - and "Custom Segments" is a first-class endpoint group in the Platform Functions API. The Campaigns page defines a campaign as "a scheduled batch job or triggered action that adds gifts... for users, typically targeted at a particular user segment", and Offers is a documented Mobile API domain. Segment-targeted, scheduled offer delivery is documented rather than marketed. Not established: predicate/rule-authoring depth - the segment endpoints manage membership, not criteria. https://developers.partech.com/docs/dev-portal-platform-functions/additional-topics/gettingstartedwithcustomsegment · retrieved 2026-08-02 adversarially verified
Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator
guest-loyalty-rfm-segmentation
Segmentation is offered, partly as a managed service, and Bridg adds shopper intelligence. Automatic named lifecycle segments (new/regular/at-risk/lapsed/VIP) computed without operator query-building are not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.
guest-loyalty-lifecycle-automation
Automated campaign generation and deployment is claimed at the PAR Intelligence layer; specific always-on birthday / first-visit / lapsed win-back triggers are not enumerated in public docs. https://partech.com/solutions/par-intelligence · retrieved 2026-08-01
Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator
guest-loyalty-native-email-sms
PAR Engagement includes a Marketing & Offers product deploying campaigns across channels; native email AND SMS sending is not separately confirmed in the pages reviewed. https://partech.com/solutions/guest-engagement-platform/ · retrieved 2026-08-01
Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.
guest-loyalty-consent-management
Citation re-pointed 2026-08-09 after the old opaque slug 301'd; quotations re-verified at the destination. Punchh's eClub Guest Upload endpoint documents per-channel consent primitives: "If the 'Explicit-Opt in' flag is enabled, marketing_email_subscription is a required parameter"; a compliance/opt-in SMS flow (send_compliance_sms with active_registration, where active_registration false plus send_compliance_sms true "will be treated as a bulk upload and no campaigns or compliance/opt-in SMS will be triggered"); terms_and_conditions and privacy_policy booleans in the user object; and a per-business validated source parameter - "only the source configured in the Punchh platform is considered valid in the API request" - which is source-of-consent capture with explicit opt-in enforcement. Shortfalls: no consent-timestamp field is documented on the upload or on the guest record (the guest webhook exposes created_at/updated_at for the user, not a per-channel consent timestamp), and nothing documents honoring revocation received by any reasonable means across all channels - only the SMS compliance flow and boolean subscription/unsubscribed flags are described. https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/eclub/post/api2/dashboard/eclub_guests · retrieved 2026-08-09 adversarially verified
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
A2P 10DLC is neither handled nor documented; the operator brings its own SMS provider account and the number on it. Punchh's Implementing SMS Marketing page puts the whole carrier relationship on the customer: 'The short code or long code that is configured in the SMS service provider must be added to the Punchh platform. For example, if your SMS service provider is Twilio, the Twilio short code or long code and other details would be added to the Punchh platform.' The page continues: 'You need to provide the Twilio From Number', 'which is a long code or short code configured in the Twilio account and will be used to send SMS messages to your guests.' Punchh's documented scope is limited to storing that number and to the START/STOP/HELP keyword templates ('Configure default responses and the short code to which guests need to reply in the Punchh platform under Loyalty Program > System Messages > SMS Notification Templates'). Absence control: the tokens '10DLC', 'A2P', 'brand registration', 'campaign registration' and 'The Campaign Registry' each occur ZERO times, word-boundary matched over whitespace-normalised text, across all 1,358 documents; the same matcher in the same run returned 115 documents for 'webhook', 16 for 'HMAC' and 588 for 'Punchh', so it can fire. Bounded to a corpus frozen 2026-09-09: partech.com's WordPress REST API across all seven public content types (799 documents; the type registry at wp-json/wp/v2/types and the Yoast sitemap index reconcile — the only sitemap entries absent from the REST census are taxonomy archives), the 531-page developers.partech.com sitemap (which equals its llms.txt exactly, so that pair is one table rendered twice and is a FLOOR, not a census), and the 28 OpenAPI documents the per-section llms.txt files name. https://developers.partech.com/docs/dev-portal-mobile/additional-topics/implementing-sms-marketing · retrieved 2026-09-09 automated extraction
Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator
guest-loyalty-campaign-attribution
Real-time dashboards claimed for participation, ROI and customer lift; tying redeemed offers to actual check totals is not documented. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator
guest-loyalty-data-export-portability
Self-serve guest-list export is documented and needs no ticket: 'The Export section provides tools for exporting customers, sales, labor, settings, and surveys' and 'The Export Customers tool produces a CSV file for download which contains customer records that match the selected filters', filterable by birthday, gender, communication preferences, order date, items ordered, preferred and signup location, signup date, email address and zip code. No fee or approval step is mentioned. SHORTFALL: transaction history is not in it - the companion Export Sales tool 'produces a file that can be imported into a third-party accounting or inventory system', formatted from the GL account mapping (QuickBooks IIF and similar), which is ledger data rather than per-guest transactions. And this is the POS customer database, not the loyalty ledger: PAR POS loyalty is retired ('no longer supported as of March 31st, 2024', including this tool's own 'Filter By Loyalty Cards'), so points, tiers and redemption history sit with the configured provider - Punchh, Paytronix, SessionM, Givex and others - whose export terms are documented only behind certification-gated or login-gated material, with support.punchh.com returning HTTP 401. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Exposes a documented outbound guest and order event API or webhook stream that a CDP or marketing platform can subscribe to (e.g. Olo, Punchh, Bridg, Klaviyo). differentiator
guest-loyalty-cdp-event-api
The Webhooks Manager documents guest create/update/delete only. A CDP event feed needs transaction/order events, which PAR explicitly does not push — its own guidance is to poll GetOrders with a ModifiedTime filter. The researcher scored 'partial' for exactly this on extensibility-webhooks-push and reporting-webhooks, then 'yes' here; inconsistent. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01 adversarially verified
Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator
guest-loyalty-review-capture-routing
Post-transaction feedback capture is documented and first-party. Receipt Footer options include 'Show QR Code' with a configurable URL and 'SMG Code: Survey code to be added to receipt for customer surveys'; the receipt and chit token list includes '%SurveyCode% - SMG survey code will be placed on receipt and or chit' and '%QualtricsSurveyCode% - Qualtrics survey code will be placed on the receipt and or chit'. Responses return into reporting: the Marketing report category carries Survey Summary, Survey Detail and Survey Question Summary; customers can be filtered by 'Surveys Taken' and 'Surveys NOT Taken' when exporting; and 'The Export Survey Results tool produces a CSV file containing survey responses for the selected survey completed within the selected date range'. SHORTFALL: no routing by score anywhere - nothing sends low scores to a private service-recovery workflow or steers high scores toward public review sites, and no review-site destination is configurable. PAR's own survey authoring is retired: the Settings Editor entries for Surveys, Survey Questions, Survey Question Groups and Survey Rating Scales all read 'This functionality is no longer supported as of March 31st, 2024', leaving the survey platform itself (SMG, Qualtrics) or a reputation partner such as Birdeye to perform capture and any routing. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.
guest-loyalty-referral-program
Referrals named as a layerable Punchh program element; per-guest codes, attribution and two-sided rewards not detailed. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator
guest-loyalty-wallet-pass
Upheld at grade B on documentation rather than the Smart Passes landing page. PAR's POS developer docs describe Apple Wallet pass integration with the POS: "Apple Loyalty Passes, part of Apple Wallet, contain various details like loyalty points, the user's name, email address, etc.", redeemed either by NFC tap on certified terminals (One-Tap Flow) or, in the Alternative Flow, by barcode - "the POS system should have a Punchh integration and a scanner to scan the user's QR code or barcode for user/redeemable look-up" - resolving through the Punchh User Look-up API. Caveat: Google Wallet appears nowhere in that document, so only the Apple side is documentation-backed; the Apple+Google "Smart Passes" pairing is a marketing claim. https://developers.partech.com/docs/dev-portal-pos/additional-topics/applepassintegrationwithpos · retrieved 2026-08-02 adversarially verified
Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.
guest-loyalty-privacy-rights-tooling
Upgraded from partial 2026-08-09; the prior inference from webhook status names is withdrawn. PAR/Punchh documents a complete business-admin DSAR toolset in the Platform Functions API, all authorized by the operator's own BUSINESS_ADMIN_KEY. Access: GET /api2/dashboard/users/info "lets you fetch a user's information by user ID, phone number, or email address", returning the full profile plus the loyalty balance object (points_balance, banked_rewards, membership_level, total_credits/debits) and reward ledger. Export: POST /api2/dashboard/users/send_user_details_export "Emails a guest export to the guest as well as the requester", with an email_admin_only flag. Deletion: DELETE /api2/dashboard/users takes a reason of delete_general, delete_test_data, anonymize_forget_me or anonymize_inactivity; Delete "Deletes the user and all associated transaction data permanently" and Anonymize "Deletes all of the user's PII (personally identifiable information), while keeping anonymized transaction data for reporting integrity. This is in compliance with GDPR/CCPA standards". Propagation is corroborated by the Webhooks Manager guest event, which states Punchh sends no guest events for deleted, anonymized or archived users "as personally identifiable information (PII) is not stored once a guest is moved into these statuses". Caveats rather than shortfalls against this claim: deletion is asynchronous (configurable grace period, default 7 days) and the guest must be deactivated first. https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users/post/api2/dashboard/users/send_user_details_export · retrieved 2026-08-09 adversarially verified
Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.
guest-loyalty-redemption-fraud-controls
Settings2's SecurityLevel enumerates OverrideDailyLoyaltyCardLimit and ApproveLoyaltyCards — a daily loyalty-card usage limit exists with role-gated override, i.e. a documented redemption velocity control of the kind the claim enumerates, plus role-gated loyalty-card approval. Shortfalls: manager approval on manual point adjustments, employee self-redemption flagging, and a loyalty-specific audit log are not documented; Punchh-side fraud tooling does not appear in the public docs. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03
Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator
guest-loyalty-ai-offer-recommendation
Sole source is the PAR Intelligence marketing page, and the researcher's own note says 'verify in a demo that it is GA, not roadmap.' A cell you cannot confirm is shipped cannot be a 'yes'. https://partech.com/solutions/par-intelligence · retrieved 2026-08-01 adversarially verified
Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.
guest-loyalty-stored-value-gift
Physical and digital gift cards with loyalty integration; explicit tie to the same guest profile and brand-wide redemption not documented. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01
Labor & workforce
Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.
labor-clock-in-at-pos
A Labor2 service exposes shifts/labor data from the POS, implying terminal-based punching; PAR OPS syncs POS timekeeping to payroll. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01
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
Enumeration of the entire employee identification surface in the 5.16r2 Admin Portal Config Guide. Per job: 'Can Login with Card: Clock-in, login, and permission authorization via magnetic card is allowed'; 'Can Login with Finger: Clock-in, login, and permission authorization via finger scan is allowed'; 'Can Login with Pin: Clock-in, login, and permission authorization via four-digit PIN is allowed'; 'Can Login with Username/Password: ONLY when Revenue Quebec is enabled'. Per employee the same methods appear (Card / Finger / PIN). The register 'Set Login' behavior's parameter is 'Login type: Prompt for type, Card, Finger Scan, or PIN'. The terminal peripheral list enumerates Coin Dispenser Name, Customer Display Name, Barcode Reader Name, MSR Type and 'Finger Scan Reader Type: Brand and model of the biometric finger scanner connected to the terminal' - no camera device exists in it. There is therefore no photo capture at punch, no facial verification, and no photo-only mode; the only biometric is fingerprint, of which PAR notes it stores 'only a hexadecimal string of data', not the fingerprint itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Supports mobile clock-in restricted by geofence or location validation for staff who do not punch at a fixed terminal.
labor-geofenced-mobile-punch
API-schema enumeration. In the PAR OPS Portal v2 OpenAPI, PUT /v2/TimeClock/ClockIn takes exactly CurrentDateTime, TimeClockID, JobID, ClockID, IsManagerOverride and DeclaredTipsAmount, plus the DCKey header - no latitude, longitude, accuracy, device or geofence parameter - and the rest of the punch surface (/v2/TimeClock, /v2/TimeClock/ClockOut, /StartBreak, /EndBreak, /Settings, /EmployeesActualTime, /EmployeesLiveTimeClocks) is likewise location-free; the TimeClockModel and LiveTimeClockData schemas carry only ClockIn, ClockOut, BreakIn, BreakOut, UnpaidBreakMinutes and identifiers. The only Latitude/Longitude in the entire PAR OPS Portal API is on the store address record, and the ShiftWorks API's timeclock endpoints (/shiftworks/Timeclock/history/{unitID}, /shiftworks/Timeclock/firstweekday/{unitID}) carry none. On the POS side punching is terminal-bound by construction: clock-in is a register function authenticated by Card, Finger Scan or PIN, and TimeClockID identifies a physical clock. No geofenced or location-validated mobile punch exists in the documented surface. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-08
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
The In-Store Resilience release notes document a 15-minute guardrail that explicitly blocks "Clocking Out" (alongside Checking Out and Cash Drawer Assignment) on the Backup Primary register immediately after it takes over from a failed primary, "to decrease the frequency of state synchronization issues." Shortfall: this is a documented restriction on offline punch actions, not a loss-free, duplicate-free reconciliation guarantee — no such guarantee is stated anywhere in the document. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.
labor-granular-rbac
SecurityLevel objects (Id, Name, Permissions, retrievable via GetSecurityLevels) carry 26+ discrete per-action booleans — VoidItems, ApproveDiscounts, ApprovePromotions, DeletePayments, AddSurcharges, DeleteSurcharges, ManageCashDrawers, CanOpenAnyDrawer, ApproveClockIn, ApproveClockOut, ApproveCheckout, ReopenOrders, SplitCheck, OverrideMaximumTipPercent and more — and Jobs bind a DefaultSecurityLevelId, so permissions are genuinely per-action rather than fixed cashier/manager/admin tiers, configured per location (Brink settings and API provisioning are location-scoped). Shortfalls: no documented permission for report access or price change (two of the claim's enumerated actions), and Admin Portal / back-office role configuration is not publicly documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03
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
Approver attribution is documented and queryable after the fact: Sales2 order history carries ApproverEmployeeId on OrderItemVoid, OrderDiscount, OrderPromotion and OrderSurcharge (each "Maps to the Id of the Employee who approved..."), alongside the applying EmployeeId, retrievable via GetOrders by business date — individual attribution, not a shared-PIN black hole. Shortfalls: no immutability guarantee is documented anywhere, and refund orders (Order.IsRefund) carry no approver field. https://brinkapiportal.parpos.com/sales2 · retrieved 2026-08-03
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
PAR POS Cloud APIs, Using SOAP APIs - the vendor's own developer portal - carries the proposition as a shipped API surface rather than as a manual screenshot. The Labor2 service is described verbatim as "Labor2 - Employee shifts, worked hours, and labor schedules", and its summary reads "Provides labor functionalities like the ability to save and retrieve labor schedules, as well as retrieve shifts recorded by the Register at a location." Three of its methods are named and described: "GetLaborSchedule - What is the Labor Schedule at this location?", "SaveLaborSchedule - Saving ScheduledShifts for this location." and "GetShifts - What are the Shifts that have been worked at this location?" - so the schedule is a first-class, writable entity in the product, and planned shifts and worked shifts are distinct retrievable record sets. PRODUCT IDENTITY IS ESTABLISHED ON THE PAGE rather than assumed from the vendor name: the endpoint template listed for the service is "http://www.brinksoftware.com/webservices/labor/v2/ILaborWebService2/{MethodName}", so Labor2 is Brink's own service, which is the product this record scores. SCOPE OF THIS CITATION, stated so it is not over-read: the API reference establishes that native labor scheduling exists, is writable, and is held separately from worked shifts. It does NOT carry the Admin Portal detail the quarantined guide held - the drag-to-create Scheduler UI, the Copy button, the "Shift Exceeds Scheduled" alert, the Weekly Labor Schedule report, or the "Exempt from Labor Schedule" job flag. Those rest on the barred PDF and are not re-cited here. RE-EVIDENCED 2026-08-30: the cell previously rested on https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf, quarantined behind a host-wide robots bar on cdn.parpos.com (user-agent group "*", "Disallow: /", re-measured 2026-08-16) and NOT re-fetched. The barred PDF is not recovered; a different document on a permitted host was found to carry the same proposition, so the quarantine stamps come off and the grade is set from the new source rather than restored from grade_before_quarantine. developers.partech.com/robots.txt was fetched whole (76 bytes, HTTP 200, one group "*", no Anthropic agent named) and matched mechanically with the shared parseRobots/refusedForUs: refusedForUs("/docs/parpos-cloud-apis/soap") returns null, and no Content-Signal reserves anything. A BARRIER THAT WAS NOT CROSSED: this page links the WSDL files themselves at cdn.parpos.com/WSDL/latest/Labor2.xml, which is the barred host. The WSDL was NOT fetched and nothing above rests on it. api.brinkpos.net was also checked as a candidate host and is NOT usable: its robots.txt names claudebot and bars it at /. The verified flag on this row records the 2026-08 adversarial pass on the VALUE, taken against the original citation; it does not carry over to this replacement document. No verification.jsonl row was added, because a re-citation is not an adversarial pass and must never be counted as one. https://developers.partech.com/docs/parpos-cloud-apis/soap · retrieved 2026-08-06 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
Upheld and re-graded D->A on the PAR OPS Portal v2 OpenAPI. GET /v2/StoreSchedule/ScheduleForecast "Returns a list of Schedule Projections and daily requirements" for a ScheduleTemplateID over a period; GET /v2/StoreSchedule/ProjectedSales returns projected sales per business date (example {BusinessDate, Amount: 1852.74, ForecastRecordType}); GET /v2/StoreScheduleForecastCharts/ProjectedData and /ActualData return a week of demand in hourly buckets (Interval 01:00:00 from StartTime 06:00:00), so projected can be read against actual. Schedule templates and scheduleBases exist at store, multiStore and administrator scope. Not established: whether the requirement is broken out by job or duty. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · 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
The Admin Portal guide documents an Admin Portal dashboard "Summary" widget showing "Net Sales, Labor cost, Sales Per Labor Hour, the number of employees Clocked In" together, and a "Sales & Labor" widget graphing net sales and labor cost by hour when viewing a single day. Shortfall: no explicit "labor cost as a percentage of sales" metric is named (only Sales Per Labor Hour), and this is documented as an Admin Portal (back-office) dashboard, not confirmed as available on a POS terminal during service. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
The Admin Portal guide documents an "Overtime" alert: "Send alert when an employee goes from regular time to overtime." Shortfall: this fires as an email alert at or after the moment of crossing into overtime, not as a clock-in warning or block before the overtime is incurred, which is what the claim requires. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
The PAR OPS (Data Central) portalV2 OpenAPI documents a jurisdiction-scoped Autocompliance rules engine: /v2/Autocompliance/MealPeriodPenalty rules are scoped by CountryID/CountryStateID/CountyID/CityID with EffectiveStartDate/EndDate and carry MinBreakMinutes, PenaltyMinutesAwarded, PenaltyRate, BreakType and ScheduleValidation; penalty lines carry BreakRequiredAfter/TakeBreakWithin and a SignedWaiver flag; RestPeriodBetweenShiftsRule and TimeclockThresholdRule (BreakIn/CheckIn/BreakDuration) are similarly jurisdiction-scoped, and the State model includes MealBreakWaiver. Missed-break premium pay is explicit (penalty minutes awarded at a penalty rate). Shortfalls: an employee-facing break attestation prompt is not documented anywhere public — waivers appear only as flags — and the POS-side 5.16r2 guide documents only generic break types, minimum-minutes enforcement and break start/end receipt printing; the compliance engine lives in the separately sold PAR OPS back office. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04
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 PAR OPS (Data Central) portalV2 OpenAPI documents a jurisdiction-scoped predictive-scheduling rules engine: /v2/Autocompliance/ScheduleRule (AutocomplianceScheduleRuleGetDto) carries CountryID/CountryStateID/CountyID/CityID, EffectiveStartDate/EndDate, Threshold, PenaltyType, PenaltyValue and DaysAdvanceNotice, validated at schedule time via /v2/StoreSchedule/ScheduleRules/Validate — an advance-notice-deadline-and-predictability-pay engine matching the claim. Shortfall: this lives in the separately sold PAR OPS back office, not the POS itself, consistent with the record's existing findings for the sibling meal-period and minor-labor Autocompliance rules. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
The PAR OPS portalV2 OpenAPI documents a minor-labor rules engine: /v2/Autocompliance/MinorRule objects scoped by CountryID/CountryStateID/CountyID/CityID with MinAge/MaxAge, SchoolInSession, Weekdays, effective dates, CanBeExempted and AllowOverride; school calendars with event dates are maintained and assignable per employee (/v2/schoolCalendars, /v2/StoreEmployee/schoolCalendar); and /v2/StoreSchedule/MinorRules/Validate plus /v2/StoreSchedule/MinorRules/Override enforce the rules at scheduling, with override explanations recorded per employee and business date. Shortfall: clock-in-time enforcement of minor rules is not documented — the POS-side 5.16r2 guide enforces only generic schedule punctuality windows at clock-in — and the engine lives in the separately sold PAR OPS back office. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · 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
The Admin Portal guide documents "Tip Pooling Enabled: Allows for the definition and management of employee tip pools," with per-job "Contribute to Tip Pool" (percentage of compensation) and "Receive Distributions from Tip Pool" flags. The PAR OPS Payroll API (already cited elsewhere in this record) separately computes TipShareHours/TipShareAmounts/TipShareJobWeights per employee per payroll period, exportable to payroll — automatic per-shift computation from configurable rules rather than a manual spreadsheet. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
The PAR OPS (Data Central) Payroll OpenAPI documents a full tip-share engine: /Payroll/TipShareHours ("Tip Share Recipients Hours" per StoreEmployee/Job), /Payroll/TipShareAmounts (CalculatedAmount, PostingAmount, Hours per StoreEmployee/Job for a payroll period), TipShareContribution models with patchable PostingAmount, /Payroll/TipShareJobWeights (OriginalPercent/PostedPercent), /Payroll/TipShareSettings (Frequency, DateFrom/Thru, AllowAdjustJobWeights, Shift) and POST /Payroll/TipShareAmountToPayroll; the portalV2 CashBalancing API adds per-employee, per-business-date CashOut records with TipShareOutAmount, and jobs carry TipShareMethodEnum {None, Contributor, Recipient} plus UseInPool. All queryable/exportable via API. Shortfalls: this lives in the PAR OPS back office, a separately sold module, not the POS itself; and a per-employee tips-received record (declared/charged tips) is not in the public spec — contributions, weights and distributed amounts are. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portal/swagger.json · retrieved 2026-08-03
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
The cash-versus-charged separation is real and machine-readable. The Delaget Connect API (the PAR OPS Insights & Delivery API linked from developers.partech.com/operations-tools/par-ops/) defines time_card with distinct 'charged_tips' and 'tips' fields alongside job_code, pay_rate, regular_hours, overtime_hours, doubletime_hours, sales, worker and a separate 'reimbursements' collection (type + amount), so charged tips, total tips and non-wage reimbursements export as distinct values per shift. The PAR OPS Portal API adds a tip-share pipeline (/Payroll/TipShareHours, /Payroll/TipShareAmounts, /Payroll/TipShareJobWeights, /Payroll/TipShareSettings, /Payroll/TipShareAmountToPayroll) and POST /v2/PayrollExport/timeclocks; Brink itself carries DeclaredTipsAmount at clock-out and the Employee Timecard Report splits Non-Cash from Declared Tips. SHORTFALL: no Treasury tipped-occupation code and no W-2 mapping. There are zero occurrences of occupation code, Box 12, Box 14 or a 'TP' code across the Delaget schema set and all three PAR OPS specs (portal 239 paths, portalV2 813 paths, shiftworks 127 paths); the worker record (first_name through home_location_id, gender, address, client_worker_identification) carries no occupation classification, and job_code is the operator's own POS job rather than a Treasury code. An operator can therefore derive cash versus charged tips but must map the Box 12 code TP and Box 14b reporting for tax year 2026 in their payroll system. https://api.delaget.com/swagger/v1/swagger.json · retrieved 2026-08-08
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
Supported by enumeration rather than by the quoted sentence: the PAR OPS page lists exactly three modules — Inventory Management, Labor Management, Reporting & Analytics — and mentions no payroll processing anywhere. PAR does not run payroll. https://partech.com/solutions/back-office-solutions/ · 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
Wrong source: a 291-entry partner directory is not evidence of export formats. The correct evidence is the PAR OPS Workforce page, which lists "Payroll export" as a bare bullet with zero detail — no named format (Gusto/ADP/Paychex/QuickBooks), no field spec. Also note the PAR OPS overview page enumerates only Inventory, Labor, and Reporting & Analytics and names no payroll providers, so 'Netchex and 7shifts' is unsourced in the pages I checked. https://partech.com/solutions/back-office-solutions/restaurant-labor-management-scheduling-software/ · 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
PAR OPS Workforce includes employee-facing applications; self-service swap/open-shift claiming with manager approval and OT/role eligibility enforcement is not documented. https://partech.com/solutions/back-office-solutions/restaurant-labor-management-scheduling-software/ · retrieved 2026-08-01
Provides digital new-hire onboarding that collects W-4 and I-9 documentation and supports E-Verify submission.
labor-digital-onboarding-i9
Both new-hire forms are first-class in the PAR OPS (Data Central) Portal API. EmployeeGetModel carries 'FederalW4', 'StateW4' and 'I9' sub-objects, and HRManagement.EmployeeI9Model is a full Form I-9 record: ResidentStatus, AlienNumber, AuthorizedToWorkUntilDate, and DocumentTitle, IssuingAuthority, DocumentNumber and ExpirationDate for each of List A, List B and List C. W-4 is modelled federally and by state (HRManagement.EmployeeW4FederalGetModel, EmployeeW4StateGetModel, W4FederalFilingStatusModel, W4StateFilingStatusModel; in v2, /v2/W4Form/federal, /v2/W4Form/state and their filingStatuses endpoints, with EmployeeW4FederalModel and EmployeeW4StateModel). SHORTFALL: no E-Verify anywhere - zero occurrences across all three PAR OPS specs (portal 239 paths, portalV2 813 paths, shiftworks 127 paths), so there is no case creation, no DHS or SSA response handling and no tentative-nonconfirmation state. Note also what the evidence does and does not show: these are data models for storing W-4 and I-9 information, not a documented new-hire-facing onboarding wizard, and PAR OPS is a separate product a Brink customer buys alongside the POS. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portal/swagger.json · retrieved 2026-08-08
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
The Admin Portal guide's "Employee Sales Summary" report lists "key performance metrics for each employee," its "Item Sales By Employee"/eligible-sales reports track item-group attach rate by employee, and "Void Details" is "grouped by employee." Shortfall: no single report is documented that names average check, items-per-check, and void/comp rate together as one per-server scorecard — the relevant metrics are spread across separate reports. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Inventory, purchasing & cost control
Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.
inventory-recipe-bom-costing
Recipe management across locations with actual-vs-theoretical costing; multi-level sub-recipes and automatic plate-cost recalculation on ingredient price change not documented. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · retrieved 2026-08-01
Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.
inventory-unit-conversion-yields
The PAR OPS (Data Central) portalV2 OpenAPI's ItemUM model stores multiple units of measure per item, each flagged as Purchase, Recipe, CountYN (count unit) and/or Waste, with an explicit ConversionFactor and a YieldPercent per unit of measure (plus CostingUnits, Tare, Thaw and ShelfLife); recipe-content models (GetItemRecipeContentsModel) expose per-ingredient ConversionFactor ('Item unit of measure conversion factor') and Yield ('Item unit of measure yield') applied in recipe costing. Inventory lives in the PAR OPS back-office module, which is where PAR implements this across its enterprise peer group. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04
Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator
inventory-theoretical-vs-actual
Downgraded on verification. Usage-variance tracking is real and configured as a first-class concept - the PAR OPS (Data Central) Portal v2 OpenAPI carries store-level NegativeUsage, VarianceUsageThreshold and EnableInventoryEstimating and item-level VarianceUsageTargetQty and NegativeUsageQtyLimit, alongside the full actual-side apparatus (Counts/PeriodData with RefreshFromTemplate and Estimate, Waste and Store Waste Templates, PurchaseManagement Invoices and PurchaseOrders, item measures carrying CostingUnits and Yield). Named shortfall: the theoretical side is undocumented. The strings "theoretical" and "ideal" appear nowhere in any of the three published specs (portal, portalV2, shiftworks), there is no recipe or menu-item-build endpoint from which POS sales could be exploded into theoretical usage, and no variance report is exposed. "Actual vs. theoretical food costing" appears only on a marketing page. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · 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
CLAIM: depletes ingredient on-hand 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. VERDICT: partial, grade A. NEW SURFACE (325th): the three anonymous PAR OPS Back Office OpenAPI specs reached from https://developers.partech.com/operations-tools/par-ops via the Swagger UI index.js at https://dc01.rmdatacentral.com/Portal1240/api/actions/index.js (1,219 paths, 1,750 schemas, 8,361,234 bytes, all HTTP 200 2026-09-17; hard-404 control on a nonsense spec name). WHAT IS SATISFIED. (a) MODIFIER-DRIVEN DEPLETION IS A FIRST-CLASS OBJECT, which the old note could not see: GET/POST /v2/POSModifier and /v2/POSModifier/Batch (plus /v2/POSModifierIF) manage what the spec calls 'Modifier with Tracking Item' rows -- schema POSModifierDtoPost requires ParentItemID+ParentUMID, ModifierItemID+ModifierUMID and TrackingItemID+TrackingUMID and carries `QuantityMultiplier` described as 'Tracking Quantity Multiplier. Can be negative. Cannot be 0.', with StartDate/EndDate effective dating. That is exactly a POS modifier mapped to the inventory item it depletes, signed so a substitution can credit as well as debit. Alongside it /v2/POSQFactors models per-item quantity factors with `QType` = "'N' Net Sales, 'G' Gross Sales, 'C' Guests, 'D' Daily Usage". (b) INGESTION IS NOT ONLY END-OF-DAY: POST /v2/POS/RealTimeImport/{dataSourceType}, /{dataSourceId} and /{storeId} are documented verbatim as 'POST RealTime Import data.' / 'Use this method as a webhook to post data to the DC RealTime Import processor.' -- a push ingestion path distinct from the batch AutoImport (ImportMode) endpoints in the same POS tag. NAMED SHORTFALL (why not yes): nothing in 1,219 paths states that ON-HAND quantities are decremented per transaction. On-hand remains a count-and-derive apparatus: /v2/Counts/DailyData/{countDate} and /v2/Counts/PeriodData/{countDate} with /Estimate, /Approve, /UnApprove, the store-level flags EnableInventoryEstimating, NegativeUsage, VarianceUsageThreshold and ShiftCounts, /v2/COGsShifts ('Returns list of available COGS shift headers'), Purchasing.InventoryShiftModel, /StoreItems/{id}/DailyUsage, /v2/Items/{itemId}/ItemDailyUsage and DailyUsageFrequencyEnum. So the finest documented depletion grain is the SHIFT or business date, not the order; 'RealTimeImport' is an ingestion webhook, and that it updates on-hand immediately is an inference the spec does not make. Tokenised controls over the 8,361,234-byte combined spec text: 'perpetual' 0, 'onhand' 0 (the concept appears only as the count model OnHandCountItemModel), 'polling' 0, 'estimat' 0 outside the count Estimate apparatus. BOUND: PAR OPS back office, production host, not the Brink register. Retrieved 2026-09-17. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-09-17 adversarially verified
Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator
inventory-86-auto-sync
Item-level 86 exists and reaches every channel, but is not ingredient-driven and is not automatic. Settings Editor has an Item Availability screen that "gives users the ability to quickly turn an item 'on' or 'off' depending on the item supply at the restaurant by utilizing the Active checkbox", and "Item availability may also be set for specific order channels (Delivery, Drive-Thru, etc.) by using the checkbox in their respective columns"; there is a matching register button that "Opens 'Item Availability' screen, which allows for setting availability of all items", and 86'd Item is a built-in Void Reason. The legacy Brink API exposes the same state to online ordering and third-party partners: Ordering.svc GetItemAvailability / UpdateItemAvailability carry ItemAvailabilityDetail (IsAvailable plus QuantityAvailable, "-1 to indicate an unlimited supply", set to 0 when IsAvailable is false), and GetUnavailableItems returns "the list of item IDs that are active but unavailable at the location on current business date", optionally filtered by DestinationId. Shortfalls: the configurable threshold drives a notification, not an 86 - the Alerts engine's Item Availability type "is sent when an item is marked 'Unavailable', when the available amount reaches a certain amount, or when an item's available amount falls below a specified threshold" (Alert if Greater Than X / Less Than X / Not Available), and it is an email alert; and the trigger is the item's own available count, not a component ingredient's stock - Brink has no ingredient stock model, so nothing 86s a menu item when an ingredient hits zero. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
PAR OPS markets reducing count effort, and PAR partnered with NomadGo for AI-powered computer-vision counting; full/spot/cycle count modes with separate variance history are not documented. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · 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
A handheld counting workflow with barcode support is enumerated in the PAR OPS (Data Central) DC_Inventory web service, whose operation list includes PDAGetCountBarcodes and PDAGetCountBarcodesZip, PDAGetLocationsList(Zip), PDAPrepareData(Zip) and PDAReceiveData(Zip), alongside GetMyCountItems, GetTemplates, ReEstimateCounts, ConvertMissingCountsToZero and UpdateInventoryLines. The prepare-data / receive-data pair is a download-to-device then upload-counts cycle, i.e. counting is not required to be online continuously. Shortfalls, all material to this claim: this is PAR OPS / Data Central, a separate back-office product a Brink operator buys alongside the POS, not a Brink POS capability; the surface is a legacy 'PDA' data-transfer pattern with no documented tablet or smartphone app, no QR support (barcodes only), and nowhere does PAR state that the device keeps accepting counts with no connectivity and syncs on reconnect - that is inferred from the operation set. Brink POS itself has no counting screen: the 5.16r2 Admin Portal guide has no inventory or count screen anywhere in its 8,425 lines. https://rmhs.rmdatacentral.com/Web1243/services/DC_Inventory.asmx · retrieved 2026-08-08
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
"Scan Assist" converts paper invoices into EDI receipts — that is invoice digitization, not a pre-built broadline distributor catalog with outbound PO transmission. No named Sysco/US Foods/PFG catalog integration documented. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01
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
Scan Assist ("Scan paper invoices for instant EDI receipts creation") is explicitly listed as a premium add-on, not part of any base PAR OPS module. Priority-1 attack: paid add-on, not native included capability. The researcher's own note said 'premium add-on' and scored yes anyway. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01 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
326th: MOVED to no. Both conjuncts now fail against the vendor's complete API spec set AND its own product marketing, and the 325th's stated reason for holding ('alerting could live in a report or notification screen with no public endpoint') is answered by the marketing page, which enumerates the product's alerting and it is the wrong alert. NEW SURFACE: the anonymous WP REST census of partech.com (content types enumerated at /wp-json/wp/v2/types, then every public type paged to x-wp-totalpages: 798 documents - 103 pages, 224 posts, 247 resource-post, 93 news-coverage, 56 press-releases, 3 testimonials, 72 sub-processors - 2,590,281 chars). PAR OPS Inventory's own product page (https://partech.com/solutions/back-office-solutions/food-inventory-management-software/) lists its On-the-Go Inventory feature set verbatim as: 'Label all food items as soon as you receive a delivery / Replace handwritten notes with easy-to-read food expiration labels / Create Prep/Pull/Thaw/Cook sheets for fresher, safer food and less waste / Set alerts to identify low-stock items before they run out'. THE ONLY ALERT PAR NAMES IN ITS INVENTORY PRODUCT IS A LOW-STOCK ALERT - that is the near-miss to record, and it is not a received-price-variance alert. The COGS Analysis section is about food cost VARIANCE and menu engineering ('reveal actual food cost for every order'), i.e. usage variance again, the same homonym the 325th found in the API as VarianceUsageThreshold. CONTROLS over the 798 documents, tokenised, case-insensitive: `price alert` 0, `vendor price` 0, `invoice` 10 hits in 9 docs and none about price tracking (the invoice feature named is 'Scan Assist: Scan paper invoices for instant EDI receipts creation'), `variance` 28 hits in 12 docs all food-cost/usage variance, `price change` 1 hit (a blog aside). Same controls over the 545-page product-docs.partech.com corpus fetched to 100% of its 546-URL sitemap this pass (4,942,116 chars): 0. This sits on top of the 325th's census of the publisher's OWN complete declared spec set for PAR OPS (3 of 3 specs named by the Swagger index at /Portal1240/api/actions/index.js; 1,219 paths, 1,750 schemas, 8,361,234 bytes), where purchase price is a single current value (LastCost / LastCostUMID, CostingMethodEnum {LastCost L, WeightedAverage W, RecipeCost S, FIFO F}) with no per-item price series across invoices, `lastprice`/`pricehistory`/`contractprice`/`catalogprice` all 0, and all 22 `threshold` hits being usage-variance or labor-autocompliance. So: no purchase-price history, and the only alert the vendor documents or markets is low stock. Retrieved 2026-09-18. MERGE NOTE (326th): graded C, not B: the cited URL is the vendor marketing host; the product-docs and API corpora are supporting bounds. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · retrieved 2026-09-18 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
The PAR OPS (Data Central) portalV2 OpenAPI's PurchaseOrderPostModel documents a per-line SuggestedOrderQuantity together with PredictionCalculationID and a PredictedUsages array of per-date forecasted usage (e.g. {"PredictionDate":"2022-12-01","Usage":2.0}) — a forecast-driven suggested purchase quantity, not only a static-par calculation. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 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
The PAR OPS portalV2 OpenAPI documents "Waste and Store Waste Templates" as a distinct object family from the usage-variance apparatus (NegativeUsage, VarianceUsageThreshold — already cited elsewhere in this record), i.e. a structured waste-logging mechanism kept separately reported from usage variance, matching the claim's requirement. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified
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
CLAIM: 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. VERDICT: yes, grade A. NEW SURFACE (325th) AND HOW IT WAS FOUND: developers.partech.com publishes a page https://developers.partech.com/operations-tools/par-ops whose entire body is two unlinked API-portal links; one is 'API Portal for PAR OPS Back Office' -> https://dc01.rmdatacentral.com/Portal1240/api/actions/index.html, a live anonymous Swagger UI whose index.js declares THREE specs. All three fetched anonymously 2026-09-17 at HTTP 200, application/json: /Portal1240/api/swagger/portal/swagger.json ('Portal Api', OpenAPI 3.0.1, 2,413,234 bytes, 242 paths, 376 schemas), /portalV2/swagger.json ('Portal Api v2+', 5,432,904 bytes, 848 paths, 1,160 schemas) and /shiftworks/swagger.json ('ShiftWorks Api', 515,096 bytes, 129 paths, 214 schemas) -- 1,219 paths and 1,750 schemas, 8,361,234 bytes, assembly version 26.18.2.11. DISCRIMINATION CONTROLS: /Portal1240/api/swagger/zzznope/swagger.json and /Portal1240/api/actions/zzznope.html both return a hard 404 with a zero-byte body, so these 200s are not a catch-all. The atlas already cites PAR OPS portalV2 at grade A on six inventory cells, but PORTAL v1 and SHIFTWORKS are new, and the Trades family had not been read. EVIDENCE: PAR OPS calls an inter-store transfer a TRADE and models it as a two-sided approved document. Endpoints: GET/POST/PATCH/DELETE /Trades and /Trades/{id}, /Trades/{id}/lines/{lineid}, POST /Trades/{id}/Accept, POST /Trades/{id}/Dispute, POST /Trades/{id}/Reinitialize (v1) and /v2/Trades, /v2/Trades/Batch, /v2/Trades/Accept, /v2/Trades/Dispute, /v2/StoreItems/Trades (v2+). Schema Purchasing.Trade carries `TradingStore` (a $ref to Common.Store, i.e. the counterparty location), `SenderManager` ('Sender manager', readOnly), `RecieverManager` ('Receiver manager', readOnly), `TradeDate`, `TradeNumber`, `Amount` ('Total amount. Type: decimal(12,2)'), an `InventoryShiftModel` Shift, and Lines. THE APPROVAL STATE IS EXPLICIT AND ENUMERATED: schema Purchasing.TradeStatus has ID with `"pattern": "I|A|D|L"` and the verbatim description 'Status identifier / I - Initialized / A - Accepted / D - Disputed / L - Locked' -- so a trade sits Initialized until the receiving store Accepts (or Disputes) it, which is the in-transit/approval state the claim asks for, and the Accept/Dispute/Reinitialize endpoints are the transitions. Purchasing.TradeLine is quantified and costed on both sides: required StoreItem plus MasterItem, Measure, `Quantity` ('MinValue is 0.000000000001, MaxValue is 9999999.999999999999'), `Cost` ('Line cost. Type: decimal(13, 4)', readOnly) and `ExtendedCost` ('Extended cost of a line. Type: decimal(12, 2)', readOnly). v2 adds RequestedTradeItemDto and SuitablePartnerStoreDto (candidate counterparty stores) and TradeDocumentDto/TradeDocumentLineDto. Every measure also carries a `TradeAllowed` flag (MeasureModel, StoreMeasureModel, ItemUM), i.e. transferability is configured per unit of measure. BOUND: delivered by PAR OPS (formerly Restaurant Magic Data Central), PAR's own back-office product that the atlas already scores at grade A for this record, not by the Brink register software; production host (dc01, Portal1240), not a staging or QA copy. Retrieved 2026-09-17. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portal/swagger.json · retrieved 2026-09-17 adversarially verified
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
The PAR OPS portalV2 OpenAPI's Vendor model carries ProductionKitchenID/ProductionKitchenDescription/ProductionKitchenNumber fields and a UsePOCostForCommissary flag — a location can be configured as an internal supply "vendor" with a designated production kitchen and a purchase-order-cost-for-commissary toggle. Shortfall: no dedicated commissary/transfer-pricing object, and no computed-transfer-cost mechanic beyond this vendor-record flag, is documented. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified
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
326th: MOVED to no. The 325th held this only because 'an API spec is a census of the API, not of the product's UI, and receiving lot capture could exist on a screen with no endpoint'. The UI-level surface is now censused too and it names the label feature explicitly - and the labels are expiry labels, not lot codes. NEW SURFACE: anonymous WP REST census of partech.com (types enumerated at /wp-json/wp/v2/types, every public type paged to x-wp-totalpages: 798 documents, 2,590,281 chars) plus product-docs.partech.com fetched to 100% of its own 546-URL sitemap (545 pages at HTTP 200, 4,942,116 chars; par-pos 164, punchh 374, guest360 7 - prior passes walked only the 164 par-pos pages). PAR OPS's own feature list on both the Inventory page and the Back Office page reads 'Prep Label Printing: Enhance inventory checks with scannable food expiration labels' and 'Replace handwritten notes with easy-to-read food expiration labels / Create Prep/Pull/Thaw/Cook sheets' - a PREP/expiry label printed in-store, with no supplier lot or batch code captured at receiving and nothing linking it forward to a sale or backward to an invoice. CONTROLS, tokenised, word-boundary, case-insensitive, over the 798 marketing documents: `traceab*` 0, `recall` 4 hits in 4 docs and all four are POISON (a drive-thru audio story, two loyalty-award posts, a case study - the verb 'recall', never a product recall), `shelf life` 0. THE POISON THAT MATTERS AND THAT AN UNTOKENISED GREP WOULD HAVE PUBLISHED AS A FALSE POSITIVE: `lot` returns 47 hits in 31 documents and every single one is the phrase 'a lot' ('a lot more eyes on the data', 'tasked with a lot', 'another restaurant's lot'). Zero are lot numbers. Same control over the 545-page product-docs corpus: `lot` 4 hits, all 'a lot'. This stands on the 325th's census of the publisher's complete declared PAR OPS spec set (3/3 specs, 1,219 paths, 8,361,234 bytes) where `lot`/`lots`/`lotnumber`/`lotno`/`traceability`/`traceable`/`recall`/`expiry`/`usebydate` are all 0 and the 96 `batchnumber` hits are the ButcherBatches yield-conversion family plus 61 generic HTTP /Batch envelopes. Neither the API, the product docs, nor the vendor's own marketing captures a lot/batch number at receiving or traces it in either direction. Retrieved 2026-09-18. MERGE NOTE (326th): graded C, not B: the cited URL is the vendor marketing host; the product-docs and API corpora are supporting bounds. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · retrieved 2026-09-18 adversarially verified
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
Expiry labelling at receiving and prep is documented; an expiring-soon report or alert is not. The PAR OPS Inventory page's On-the-Go Inventory section lists 'Label all food items as soon as you receive a delivery', 'Replace handwritten notes with easy-to-read food expiration labels' and 'Create Prep/Pull/Thaw/Cook sheets for fresher, safer food and less waste'. Shortfall: the only alerting the page describes is stock-level, not date — 'Set alerts to identify low-stock items before they run out' — and no expiring-soon report, use-by dashboard or date-driven alert is published. Absence control: 'shelf life' occurs ZERO times across all 1,358 documents and 'expiration' occurs in 4, of which this page is one. https://partech.com/solutions/back-office-solutions/food-inventory-management-software/ · retrieved 2026-09-09 automated extraction
Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.
inventory-bar-partial-bottle
CLAIM: supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting. VERDICT: partial, grade A. NEW SURFACE (325th): the three anonymous PAR OPS Back Office OpenAPI specs (see inventory-transfers for provenance, byte counts and the hard-404 control). EVIDENCE. (1) A COUNT LINE IS RECORDED IN THREE UNITS AT ONCE, not one. Schema Counts.OnHandCountItemModel (and CountItemModel, CountItemPeriodModel, CountItemPostModel, CountTemplates.ItemCountTemplateDto) carries WholeUMID/WholeUMDescription/WholeQWeight/WholeQuantity, **PartialUMID/PartialUMDescription/PartialQWeight/PartialQuantity**, EachUMID/EachUMDescription/EachQWeight/EachQuantity plus a SummaryUMID and a rolled-up Quantity, with LocationID/LocationDescription, Bin and Shelf. The vendor's OWN EXAMPLE PAYLOAD in the spec is a bar: `"LocationDescription":"TheBar","Bin":"Fizzy","UMDescription":"Ounce","WholeUMDescription":"Ounce","WholeQWeight":1.0,"PartialUMDescription":"Case","PartialQWeight":0.666667,"EachUMDescription":"Bottle","EachQWeight":0.0333333` -- i.e. a beverage item whose summary unit is the OUNCE, whose Each unit is the BOTTLE, and whose partial quantity converts by an explicit weight factor. Counting a part-full bottle as ounces remaining is therefore representable. (2) A PER-MEASURE TARE WEIGHT EXISTS, which only weighing needs: every measure model in the API -- Purchasing.MeasureModel, StoreMeasureModel, StoreMeasureExtendedModel, v2 MeasureModel/PostMeasureModel/PatchMeasureModel, Purchase.StoreMeasureModel and Item.ItemUM -- carries `Tare`, described verbatim as 'Item measure Tare Weight', number, minimum 0, maximum 99999999.9999, next to ConversionFactor, YieldPercent, CostingUnits and the CountAllowed/PurchaseAllowed/WasteAllowed/TradeAllowed permission flags. NAMED SHORTFALL (why not yes): no connected SCALE DEVICE integration is documented anywhere -- tokenised controls over the 8,361,234-byte combined spec text give 'pour' 0, 'jigger' 0, 'tenth' 0, 'fraction' 0, 'shrinkage' 0, and the only 'scale' hits are 15, of which the item-relevant ones are a temperature scale ('Temperature scale. [F]ahrenheit, [C]elsius', enum TempScaleEnum) and a boolean `Scale` on ScheduleStation/MultiStoreScheduleStation, i.e. LABOR scheduling -- BOTH ARE POISON FOR THIS CLAIM AND ARE RECORDED SO THEY ARE NOT MISREAD AS WEIGHING. PAR OPS also names no partial-bottle or tenths feature as such; the capability is the generic three-unit count plus Tare, which is why this is partial rather than yes. BOUND: PAR OPS back office, production host, not the Brink register. Retrieved 2026-09-17. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-09-17 adversarially verified
Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.
inventory-cogs-gl-export
The PAR OPS portalV2 OpenAPI documents dedicated named-format export endpoints: POST /v2/QuickBooks/ExportAccountingData ("Exports Accounting Data into QuickBooks according to GL export format") and POST /v2/QuickBooks/ExportPurchases ("Exports purchase documents into QuickBooks" — Bills and Vendor Credits), plus /v2/ChartOfAccounts/{id}/Mappings and a Meta-Accounts model whose FlagField values include Expense, Inventory, Tax, POSAdjustment and more — configurable GL account mapping in a named accounting system's import format. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · retrieved 2026-08-04 adversarially verified
Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator
inventory-native-not-partner
PAR OPS (Restaurant Magic Software, a PAR company) publishes its own web-service reference at rmhs.rmdatacentral.com/Web1243/services/. DC_Item documents recipe costing primitives directly: GetRecipeCards, GetRecipeCardsHtml, UpdateRecipeCard / UpdateRecipeCardEx, DeleteRecipeCard, GetRecipeIngredients, UpdateRecipeIngredient, DeleteRecipeIngredient, FinalizeBulkRecipesUpdate, plus item, item-group and unit-of-measure maintenance and LinkItemToPLU ("Link DC Item to PLU Item") tying the inventory item to the POS menu item. DC_Inventory documents the counting and costing cycle - CalculateCountCost ("Calculate count cost"), ReCalculateInventoryRecipes ("Re-calculate inventory recipes"), ReEstimateCounts, SyncInventoryWithTemplate, ApproveInventory/UnapproveInventory, GetInventoryLines/UpdateInventoryLines and PDA count-sheet transfer; DC_Purchasing covers purchase orders, invoices, credit and trade memos, and vendors. Named shortfall of packaging, not of ownership: none of this appears anywhere in the 306-page Brink POS Admin Portal guide (zero occurrences of "inventory"), so inventory and recipe costing are a separately-licensed PAR module rather than a Brink POS feature - but the module is PAR's own, not a contracted third party such as MarginEdge or Restaurant365. https://rmhs.rmdatacentral.com/Web1243/services/DC_Item.asmx · retrieved 2026-08-06 adversarially verified
Reporting, BI & data access
Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.
reporting-realtime-dashboard
The cited Cloud POS page's actual wording is "fully cloud-enabled, which means you can manage menus, pricing, and reporting remotely." Remote access to reporting is not a documented real-time dashboard, and the researcher concedes mobile access is unconfirmed. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01 adversarially verified
Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.
reporting-eod-closeout
A Sales2 service exposes deposits and tills via API; a single canned EOD document reconciling gross/net/tax/tips/discounts/refunds/tenders is not documented publicly. https://brinkapiportal.parpos.com/ · 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
The substrate is documented at modifier grain: Sales2 order detail carries OrderItemModifier ("Modifiers applied to this OrderItem") with Price, and each order item maps DayPartId and RevenueCenterId, so item- and modifier-level mix by daypart and revenue center is extractable via GetOrders; PAR OPS additionally treats PmixTracking as a first-class account category in its Chart of Accounts API. Shortfall: the claim asks for a PMIX report in the reporting UI, and no PAR-published report documentation (a modifier-level PMIX screen or export with those filters) exists publicly. https://brinkapiportal.parpos.com/sales2 · retrieved 2026-08-03
Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.
reporting-comps-voids-audit
The Admin Portal guide documents "Void Details" (grouped by employee, sorted by void time), "Void Summary" (totals by void reason), and "Manager Override Detail" ("Lists details regarding all manager override actions, including: Approval Time, Login User, Button Name, Button Action, Approval User, and Approval Method") — together an audit trail of voids/comps/discounts/overrides attributing both the applying and approving employee, with reason codes and timestamps. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
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
Sales2 exposes tills and deposits, the raw inputs for over/short; a per-drawer/per-shift/per-employee over-short report is not documented. https://brinkapiportal.parpos.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
PAR OPS provides labor management with KPI reporting against POS sales; specific SPLH and labor-% by hour/department/employee cuts not documented. https://partech.com/solutions/back-office-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
Same evidence as labor-server-performance-metrics: Employee Sales Summary, Item Sales By Employee/eligible-sales-%, and Void Details (grouped by employee) are documented, but no single per-server report combines average check, items-per-check, and tip percentage as one scorecard. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator
reporting-channel-profitability
PAR OPS Delivery Operations reconciles DSP payouts and commissions in one dashboard, giving per-marketplace net revenue; dine-in vs direct-online margin comparison is not documented. https://partech.com/solutions/insights-and-delivery-solutions/ · retrieved 2026-08-01
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
Marketing-page 'yes' where the note itself says drill-down to individual transaction is not documented. Drill-down is the sub-feature. https://partech.com/solutions/back-office-solutions/ · retrieved 2026-08-01 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
The Administrator Portal's Reports section enumerates a fixed catalog of roughly sixty named canned reports across Sales, Employees, Inventory, Comparative and Audits categories (Product Mix, Sales Summary, Void Details, Employee Productivity, etc.), each with a fixed description of its columns and filters. No self-service tool for choosing dimensions/measures/filters and saving a custom report is described anywhere in the guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
The Admin Portal guide documents "Scheduled Reports": "reports that are automatically generated and sent via email at a particular time or system event," configurable by Schedule Type (End of Day/Specific Time), Days of Week, Report Locations, a list of attached Reports, and a "Recipients: Email addresses to send the reports to" field. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
PAR's own configuration guide closes the enumeration: "The Export section provides tools for exporting customers, sales, labor, settings, and surveys." Each is a download, not a delivery - Export Customers "produces a CSV file for download", Export Sales "produces a file that can be imported into a third-party accounting or inventory system" formatted from the GL account mapping (QuickBooks IIF is the example), Export Labor "produces a file that can be imported into a third-party payroll system", Export Settings "produces a CSV file" and "Currently, only items can be exported", Export Surveys a CSV. The one automated recurring mechanism is Scheduled Reports, and it emails finished reports: "Reports that are to be generated and attached as PDFs to the email." No S3, SFTP, warehouse, Snowflake or BigQuery destination appears anywhere in the 8,425-line guide (SFTP and FTP: zero occurrences). Independently, the transaction API pushes nothing and is deliberately slow: Sales2.svc GetOrders takes a single BusinessDate, the Brink API FAQ says only GetHouseAccountCharges, GetLaborSchedule and GetFutureDateOrders accept a date range and "Otherwise... you will have to make a loop that will call the API with those business dates individually", under a best practice of "5 concurrent calls with a sleep of 2-3 minutes in between calls". Caveat stated rather than hidden: PAR sells Delaget / PAR Intelligence as a separate analytics product, and this finding is about Brink POS itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
Documented REST and SOAP APIs cover orders, sales, labor, settings and payments and are readable without a signed agreement — but credentials are not self-service; PAR must provision an API account against each location. https://developers.partech.com/ · retrieved 2026-08-01
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
Webhooks Manager documents guest lifecycle events. For POS orders the documented pattern is polling GetOrders with a ModifiedTime filter, not push. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01
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
Above-store data access through the API is inside a separately-feed tier; the standard subscription is not shown to exclude API access, and the report catalogue itself is not shown to be metered at all. PAR's API Service Level Commitment (v2.0, 11.14.25) covers, in its own words, "for order requests and for data requests through the API", sets a separate API Data Request Service Level Commitment in its section 2 whose remedy is a credit of "monthly subscription Fees for API Services", and is available to customers who "have elected to pay additional Fees based upon the number of Customer's eligible integrations to the PAR POS Services" (https://partech.com/doc/05-service-level-commitment-api-services-par-pos-services/). The base Service Level Commitment for PAR POS Services, which requires no fee election, is the control on how far that goes: it commits to uptime for a transaction "using a point of sale terminal or using the in-store API", and says of the above-store portal that "this Above-Store Admin. Portal Availability Service Level Commitment does not include API Services which are separately covered by the API Service Level Commitment". So the surcharge attaches to the above-store, third-party-integration API, not to API use as such. Shortfall: that above-store surcharge is documented, its base is per named API account token rather than the per-location fee this claim names, and its amount is unpublished. No revenue share and no enterprise-only requirement is documented anywhere. And the raw-data half of the claim is only partly reached - whether the Admin Portal report catalogue itself carries a tier or a metered fee is still open (see reporting-tier-paywall and reporting-history-retention, both unknown), so a conjunction of one documented surcharge and two unresolved siblings cannot support a stronger verdict than this. https://partech.com/wp-content/uploads/2026/02/08-Service-Level-Commitment-PAR-POS-Services-v2.0-2025-11-14.pdf · retrieved 2026-09-12 adversarially verified
Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator
reporting-tier-paywall
329th: MOVED unknown -> partial. CLAIM: core reporting beyond basic sales summaries (labor vs sales, PMIX, comps/voids audit, multi-location comparison) is on the entry-level paid plan rather than a higher tier or an add-on analytics SKU. VERDICT: partial - every named report is in the BASE Admin Portal report catalogue and PAR's own docs mark paid add-ons elsewhere and mark none of these, but PAR publishes no plan/tier structure at all, so the 'entry-level plan' conjunct is unverified. EVIDENCE, all four conjuncts present in the catalogue of the PAR POS 5.16r2 Administrator Portal Configuration Guide (fetched this pass from a NEW host, https://cdn.brinkpos.net/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf, 13,712,244 B, copyright 2026, 434,910 chars extracted; the same catalogue is on product-docs): 'Reports are organized into categories.'; Labor vs sales - 'Hourly Sales And Labor ... Lists sales and labor key metrics by hour' and 'Sales And Labor Summary By Location'; PMIX - 'Product Mix'; comps/voids audit - 'Void Details: Lists voided item details, grouped by employee and sorted by void time', 'Void Summary: Lists void totals for all void reasons', 'Discount Detail', 'Discount Summary', plus an Audits category with 'Manager Override Detail: Lists details regarding all manager override actions, including: Approval Time, Login User, Button Name, Button Action, Approval User, and Approval Method'; multi-location comparison - a whole 'Comparative' category, e.g. 'Hourly Sales: Lists sales totals for two groups of locations by hour, along with comparative value between the two groups of locations' and 'Menu Comparison: Displays items that have any different values set between two locations'. THE NEW ARGUMENT, a publisher-convention enumeration: product-docs.partech.com DOES flag gated features with an explicit callout - 'Added Module: Smart Passes is available for an additional cost', 'The Coupons feature is bundled as part of the Coupons and Promos Module available for an additional cost', 'Advanced Authentication is an added module available for an additional cost' - and the string `additional cost` fires in 28 of the 545 pages while `Added Module` fires in 39, EVERY ONE of them a Punchh page and ZERO of them under /docs/par-pos/ (denominator 219 PAR POS pages, 164 sitemap + 55 orphans). So where PAR gates a capability behind a paid module it says so in the docs, and it says so nowhere about any PAR POS report. NAMED SHORTFALL (why not yes): (1) PAR publishes no plan table or price list for PAR POS - re-confirmed this pass, partech.com/products/brink-pos/ now redirects to a PAR OPS page whose only pricing text is 'Pricing depends on your business size and needs. PAR OPS offers flexible plans for multi-location restaurants of all sizes (ideally 20+ locations). Contact a PAR OPS sales rep'; (2) PAR sold TWO Brink editions, 'Brink POS(R) Enterprise' and 'Brink POS(R) SMB' (both in its own product nav), and the SMB product page is now HTTP 404 - only its 2024-03-18 Wayback copy survives, saying of the SMB edition 'Right-sized pricing without hidden fees or surprise add-ons' and 'Get real-time actionable insights and reports into business performance' (grade D, retired, corroborating only); (3) PAR OPS sells 'enterprise reporting & analytics' as a module of a separately-priced product. Nothing shows the four report families being withheld from any edition, and nothing published confirms they are in the entry edition. Retrieved 2026-09-18. https://product-docs.partech.com/docs/par-pos/user-guides/admin-portal-guide/reports · retrieved 2026-09-18 adversarially verified
Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator
reporting-history-retention
326th: MOVED to no. The claim is PUBLICATION-shaped - 'Documents a historical retention window of at least 24 months of transaction-level detail' - so a complete census of what PAR publishes settles it, and PAR documents no window at all. NEW SURFACE, the last one that was missing: partech.com itself is WordPress and wide open (robots.txt 'User-agent: * / Disallow:' i.e. allow-all, plus Crawl-delay: 10), and its WP REST API is anonymous. I enumerated the CONTENT TYPES first (https://partech.com/wp-json/wp/v2/types) rather than guessing, then paged every public one to its x-wp-totalpages: pages 103, posts 224, resource-post 247, news-coverage 93, press-releases 56, testimonials 3, sub-processors 72 = 798 documents, 2,590,281 chars of stripped body text. That is a census of the marketing site's own content model, not a sitemap subset. I also re-fetched product-docs.partech.com to 100% of its own sitemap this time (546 <loc>, 545 doc pages fetched as markdown at HTTP 200, 0 failures, 4,942,116 chars: par-pos 164, punchh 374, guest360 7) - prior passes had only walked the 164 par-pos pages. CONTROLS, tokenised, word-boundary, case-insensitive, over the 798 marketing documents: `24 months` 0, `two years` 7 hits and every one is a customer-award or trend-piece sentence, `months of` 5 and all poison (loyalty campaign results, program management). `retention` fires 123 times in 53 of 798 documents and NOT ONE is data or reporting retention - it is GUEST/CUSTOMER/EMPLOYEE retention ('98% Retention rate for PAR OPS customers', 'boost guest retention and repeat visits', 'incentivizing retention while reducing labor costs', loyalty cohort retention) plus personal-data retention clauses in the privacy/cookie policies. THAT IS THE POISON TO RECORD FOR THIS CELL ACROSS ALL PAR CORPORA: in a loyalty-and-labor vendor's corpus, `retention` is almost never about data. Same control over the 545-page product-docs corpus: 44 hits in 13 files, all either guest-retention (guest360 dashboard, 13), Punchh win-back campaigns, or the In-Store Resilience BackupRetentionPeriodInDays local register backup (default 30 days) already on the record. Combined with the corpora already recorded - 531-URL developers.partech.com (6,843,305 chars, `retention` 0, `archive` 0), the 1,219-path PAR OPS Back Office OpenAPI set (8,361,234 bytes, `retention` 0), and the 1,102-body supportcenter.partech.com Aura census - PAR publishes no transaction-detail retention window anywhere, at any length. The only retention figure in the entire published estate remains the Revenu Quebec register statement ('Report data is stored on the register for up to 2 years'), which is a jurisdiction-specific local-register ceiling, not a documented reporting window. Retrieved 2026-09-18. MERGE NOTE (326th): graded C, not B: the cited URL is the vendor marketing host; the product-docs and API corpora are supporting bounds. https://partech.com/wp-json/wp/v2/pages?per_page=100 · retrieved 2026-09-18 adversarially verified
Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator
reporting-anomaly-alerts
PAR Intelligence claims a prioritized view of where to focus and proactive loss identification; operator-configurable metric thresholds with push/email alerts are not documented. https://partech.com/solutions/par-intelligence · 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
PAR Intelligence is marketed as an agentic system that surfaces insights and recommends next actions across 12B+ transactions; a natural-language ad-hoc query interface returning a figure or chart is not explicitly documented. https://partech.com/solutions/par-intelligence · 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
The Punchh page I read supports only "real-time dashboards track participation, ROI, and performance metrics" plus open APIs. New-vs-returning, frequency, and lifetime-spend cohort reporting is not documented; Bridg is an identity-resolution acquisition, not a documented cohort report. https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01 adversarially verified
Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator
reporting-sales-forecast
Upheld and re-graded D->A; the granularity question the researcher left open is now answered. The PAR OPS Portal v2 OpenAPI documents GET /v2/Forecast/{forecastId}/{date} returning seven days across Sales, Entree, Checks and Guests categories; SevenDaysSales and SevenDaysEntrees category filters; POST /v2/Forecast/Regenerate/{forecastId}/{date}, which "will cancel all applied revises"; PATCH /v2/Forecast/ByMinutes and /MultiUnit/ByMinutes setting revised amounts "for the specific forecast and time", i.e. intra-day granularity; SevenDaysLock/UnLock and Revise at unit and multi-unit scope; GET /v2/Forecast/SevenDaysWeather/{date} as a forecast input; GET /v2/Forecast/Formats; and /v2/EventForecast plus /v2/StoreEventForecast with targets and a sales chart. https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json · 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
The Employee Timecard Report shows per-employee, per-shift Non-Cash Tips (charged) alongside Declared Tips, with signature lines for employee and supervisor; 'Must Declare Tips' prompts declaration at clock-out with an optional system-calculated minimum (5.16r2 Admin Portal guide), and the Admin Portal ships a Declared Tips report plus tax reports (Tax Summary grouping tax collected by tax per location, Taxes by Day Part, Tax Exempt Sales, Tax By Item). Shortfalls: no tip-pool distribution detail report appears in the documented Admin Portal report list — pooling contribution/distribution is configurable on jobs but distributed amounts are only exposed via the separately sold PAR OPS payroll API — and no jurisdictional tax-liability rollup beyond per-location, per-tax summaries is documented. https://cdn.parpos.com/docs/Employee%20Timecard%20Report.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read
Multi-location, franchise & enterprise governance
Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.
multi-location-org-hierarchy
The API models a two-level business/location hierarchy via paired business and location tokens. A named three-level enterprise > region > location object that reporting and permissions scope to is not documented. https://brinkapiportal.parpos.com/bestpracticeandfaqs · 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
Re-examined 2026-08-08 against the sections the earlier pass missed. Brink's corporate configuration model is a one-way cascade, not a lock: Settings Editor is explicitly per-location ("Location drop-down list: Lists all locations available to the current user, configuration for the selected location is visible"), and corporate change is distributed by Changeset Publisher, which packages changesets made at an originating location and publishes them to target locations or location groups immediately or at End of Day, with per-location publish status, Retry and Download Errors. The Brink API FAQ describes the same pattern - "Changes should be published on one location and once tested on a single location, they may be cascaded ahead to other locations". Access control is by function and location, not by field: Roles carry "Rights: Functions that are visible and allowed" plus a Rank, and Users carry Limit Locations and Limit Roles. Nothing in the guide describes a per-field override or a corporate lock on specific item attributes; tellingly, PAR ships a Menu Comparison report that "Displays items that have any different values set between two locations", implying divergence is detected after the fact rather than prevented. Left unknown rather than scored no because the guide does not enumerate the individual Rights available to a Role, so a field-level restriction inside that list cannot be excluded. Re-examined 2026-09-12 against PAR Ordering's Management Center, documented in the 1,109-article PAR Support Center the prior passes had not reached. It has the level hierarchy the claim describes - core product, brand menu, store menu, with "You can override hidden items from higher levels (like the brand menu) for a specific store menu" - and it does gate by role, publishing a per-article access matrix. But it gates the opposite way from the claim: Store Manager is marked unavailable for product visibility at both brand and store level and for item price at both Store Group and Store scope, and price is locked out of the store level entirely - "In case of a Store, Price Groups are set on a Store Group level and cannot be modified on a Store level". So in PAR Ordering nothing is store-editable, and in Brink POS the Settings Editor remains fully per-location with corporate change pushed by Changeset Publisher. Neither product is per-field override with corporate locks, but the original reason for unknown stands unchanged: the Brink guide still does not enumerate the individual Rights inside a Role, so a field-level restriction there cannot be excluded. ADDENDUM 2026-09-16: CLAIM: corporate menu items expose per-field override rules; locked fields are not editable at store level. VERDICT: stays unknown for Brink. The support centre documents a real brand-vs-store model, but for PAR Ordering, a sibling product. EVIDENCE: store menus may hide items ("You can override hidden items from higher levels (like the brand menu) for a specific store menu", Brand Manager only, https://supportcenter.partech.com/s/article/How-to-Control-Product-Visibility-in-Store-Menus); "Creating, editing, and deleting categories requires brand-level access. Store-level users cannot perform these actions." (https://supportcenter.partech.com/s/article/How-to-Use-Virtual-Categories); "At the store level, admins can hide a specific inherited code from a specific product, but they cannot add codes that don't already exist in the brand library" and "If a modifier code has a price synced from PAR POS, that price overrides the menu price" (https://supportcenter.partech.com/s/article/Modifier-Code-Management); delivery fees: "If a brand switches from 'Edit' to 'Read-only' store permission settings for delivery fees ... The store will then be required to use the delivery fee type and settings configured at the brand level" (https://supportcenter.partech.com/s/article/how-to-add-a-delivery-fee); store serving times "override brand-level serving times". None is a per-field lock on corporate menu items (name/image/recipe) inside PAR POS, and online prices are pulled from the POS. A lead for a partial if the atlas scores PAR Ordering as this product's digital layer. New surface: full anonymous Salesforce Aura census of supportcenter.partech.com (Knowledge__kav.Customer_Facing_Answer__c + Title; sitemap-topicarticle-1.xml 1,103 slugs + href fixpoint = 1,109 slugs probed, 1,102 bodies held, 5.6M chars; 7 unresolved, 6 of them hrefs copied from other vendors' KBs). Most of the corpus documents PAR Ordering (formerly MENU; Management Center/CMS), a sibling product that injects orders into PAR POS (Brink); only 31 bodies say Brink. Retrieved 2026-09-16. || 320th: NEW (not moved). NEW SURFACE WORK (320th): product-docs.partech.com re-derived: sitemap.xml 546 <loc>, 164 under /docs/par-pos/ (163 held by the 319th + the ingenico Move 5000 Canada page, now fetched at 200). HREF FIXPOINT over those bodies names 66 non-image /docs/par-pos/ URLs ABSENT from the sitemap: 55 serve markdown at 200 (mostly learning-resources/step-by-step-guides/*) and 11 return the Scalar 404 page (15,132 B): POS-Release-Notes/5.16r4-release-notes and 5.16r4-features-qrg, api-release-notes/build-0-2-135 and build-0-2-152, miscellaneous/In-Store-Resilience-Backup-Primary-Feature-Notes, PAR-POS-Network-Connectivity-Requirements/legal-notice-endpoint-addendum and /stack-assignment, learning-resources/troubleshooting/par-pay, par-phase-terminal, par-tablet-8, Integration-Settings-Portal-User-Guide/overview. So the portal is NOT a census (live pages link to unpublished/withdrawn ones) and cannot carry a `no`. Corpus searched: 219 PAR POS pages (164 sitemap + 55 orphans). The current Brink Roles page still does not enumerate Rights: 'Roles control the areas and functions of the Admin Portal and Settings Editor that a user ... can access. Ranks can be assigned to roles to limit which other users a given user can view or edit.', fields Name, Rank, 'Rights: Functions that are visible and allowed.' (https://product-docs.partech.com/docs/par-pos/user-guides/admin-portal-guide/configuration/roles-users). Staff > Permissions governs POS buttons ('Permissions are used to control access to buttons'), not Settings Editor fields. Controls over 219 pages: lock/locked/locks 14, ALL POISON (Changeset Publisher 'per-location lock so multiple locations can publish in parallel safely', DB lock contention, time-punch soft lock, tablet 'No current order' lock screen, 'Account temporarily locked'); read-only 2 POISON (a script flag, an address-notes panel); corporate 2 (dashboard Ownership Type filter Corporate/Franchisee; RevQ bilingual corporate reporting). No per-field lock found, but Rights remain unenumerated, so no `no`. VERDICT: stays unknown. Retrieved 2026-09-16. || 326th: 326th: THE ONE ROUTE THAT COULD HAVE ENUMERATED A ROLE'S RIGHTS IS MEASURABLY CLOSED - recorded so no future pass spends time on it. Every prior pass held this cell on exactly one gap: the Brink guide describes a Role's 'Rights: Functions that are visible and allowed' but never enumerates them, so a field-level restriction inside that list cannot be excluded. The natural instrument is the Brink SOAP Settings service description. IT IS NOT PUBLISHED. Probed with curl and a browser UA 2026-09-18: https://api.brinkpos.net/Settings.svc?wsdl returns HTTP 200 but only a 1,726-byte WCF stub whose body reads 'This is a Windows Communication Foundation service. Metadata publishing for this service is currently disabled.'; ?singleWsdl returns the identical 1,726 bytes; /mex 301s. The same stub comes back for Sales.svc, Labor.svc and Ordering.svc and for api2.brinkpos.net. NONSENSE CONTROL: https://api.brinkpos.net/ZzzNope.svc?wsdl returns a hard 404 with 0 bytes, so the 200 is a real endpoint refusing metadata, not a catch-all. There is therefore no anonymous WSDL enumeration of Brink's Settings entities, and the Rights list remains unenumerable from any public surface. Also checked this pass and empty for this cell: the 798-document anonymous WP REST census of partech.com (types enumerated at /wp-json/wp/v2/types, every public type paged to x-wp-totalpages) contains no role, rights or field-lock documentation, and product-docs.partech.com fetched to 100% of its 546-URL sitemap (545 pages at 200) still carries only the unenumerated Roles page. Retrieved 2026-09-18. || 329th: 329th: NEW SURFACE, and it NARROWS the one gap every prior pass named (Role 'Rights' unenumerated) without closing it. The Brink Admin Portal login page (https://admin.brinkpos.net/ -> https://admin.parpos.com/Public/Login, 8,658 B, 'Version 5.0.16391') points at an UNLINKED legacy documentation index on a host no prior pass touched: https://cdn.brinkpos.net/Documentation.html (5,728 B; nonsense control /ZzzNope123.html = HTTP 403, so the 200 is real) plus siblings StepByStepGuides.html (72 links, 4,435 B), HowToVideos.html, Troubleshooting.html, Downloads.html and SMX.html. ROBOTS, recorded: cdn.brinkpos.net/robots.txt 301s to cdn.parpos.com/robots.txt, which is a generic 'User-agent: *' ... 'Disallow: /' (174 B) naming no AI crawler - read like a browser under the owner's standing order. WHAT IT HELD: the Staff Management Experience overview PDF (690,053 B, 18 pages) closes with a section 'Granting Admin Portal Rights' that shows the SHAPE of the Rights tree for the first time in any public artefact: 'Admin Portal > Configuration > Roles > Role > All Settings >' with children 'Employees, Jobs, Permissions, Security Levels, Share Staff (enables employee sharing and change rights)', and 'Admin Portal > Configuration > Roles > Role > All Reports > Audit > Staff Audit'. The granularity unit is therefore the SETTINGS ENTITY or the REPORT, under two parent nodes 'All Settings' and 'All Reports' - consistent with the guide's 'Rights: Functions that are visible and allowed' - not the FIELD. The same PDF confirms the per-location model the claim would have to override: every Staff entity screen begins 'Select a location from the Location dropdown', and corporate propagation is whole-entity Sharing ('When Job "Manager" is shared with additional locations, the Security Level ... and Permissions ... are also shared'), not a field-scoped lock. Also fetched this pass and corroborating only (2020, retired from the index): the Changeset Creation & Management QRG, https://cdn.brinkpos.net/docs/5.0%20Changeset%20Publisher%20Quick%20Ref%20Guide.pdf, 481,787 B - packages of changesets published to selected locations immediately or after EOD, with no per-field lock anywhere in it. STILL UNKNOWN: this exposes two Rights nodes, not the enumeration, so a field-level right elsewhere under 'All Settings' cannot be excluded. Per-cell re-greps run this pass over every corpus on disk (2,251 docs, 35,773,075 chars: 545 product-docs pages, 531 developers.partech.com pages, 1,102 supportcenter Aura bodies, the 798-doc partech.com WP census, 37 q323 app bundles, 15 API specs, the 5.16r2 Admin Portal guide): tokenised `read-only` 33 hits / `read only` 43 - all Punchh or Guest360 role copy; `field level` 2 - a SOCi data-field table and a PortalV2 rule-set diff; `not editable` 4 - the closest is PAR Ordering's order-regret setting, 'this settiing is not editable on store level', a sibling product; `cannot be edited` 16, none about a corporate menu lock; `locked by` 2, both poison. Retrieved 2026-09-18. adversarially verified
Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.
multi-location-price-zones
PriceLevel plus SavePriceChanges/UpdateItemPrice allow per-location prices without duplicating the item; formal price zones/groups spanning channel and daypart are not documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01
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
Changeset Publisher schedules a changeset package to publish "Immediately" or at "End of Day" — the target location's own End of Day time, itself a per-location setting — up to two weeks in advance, with a pre-validation check before submission. Shortfall: no rollback-to-prior-state after activation is documented; Cancel/Retry apply only before or during publishing. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
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
PAR markets "Fast Multi-location Rollouts" with on-time opening rates approaching 99%; a documented cloneable configuration template and a published expected time-to-open are not provided. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01
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 Admin Portal guide documents an "Ownership Types" attribute on locations — "All Ownership Types, Corporate, or Franchisee" — filterable in the Admin Portal. Shortfall: no documented permission boundary distinguishing what a corporate user can see/enforce versus what stays under exclusive franchisee control (employees, banking, labor data) — only the ownership-type tag itself is documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
The Admin Portal guide documents royalty entries defined as a percent of net sales or a flat dollar amount per month, with Start/End Date effective ranges and a "Limit Location" scope, feeding the "Royalties by Location" report. Shortfall: only a net-sales basis is documented — no configurable gross-vs-net-of-discounts/comps/third-party basis toggle was found, and calculation is report-driven rather than documented as executing unattended on a defined schedule. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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 Admin Portal guide's Options > Accounting > Royalties tab carries Bank Account Number and Routing Number fields stated to appear "on the Royalties by Location report." Shortfall: no automated ACH/debit collection execution flow is documented — these are display/reporting fields, not a documented collection mechanism — and no franchisee-visible statement artifact is described. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read 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
Enterprise reporting and analytics consolidate performance across locations with KPI management; store-vs-store ranking and variance flags not explicitly documented. https://partech.com/solutions/back-office-solutions/ · 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
Cross-location item rollup exists; the shared corporate item identity the claim requires does not. Product Mix > All Items "Lists all items and their sales totals, sorted by percent of total sales. Can be run for one or more locations, for a given date range", and the whole Product Mix family (By Brand, By Day Part, By Destination, By Interval, By Item Group, By Revenue Center, By Section) is multi-location; the Comparative category adds a Product Mix report that "Lists sales totals for two groups of locations by item, along with comparative value between the two groups of locations, sorted by item name". Locations are organised for this by Location Groups, which "allow you to arrange locations in a hierarchical fashion", can be nested, and replace the older Locations and Report Groups. Shortfalls: the reports are documented as grouped and sorted by item name, not by a corporate identifier, so an item a store renamed would not obviously roll up with its siblings; PAR provides a Menu Comparison report precisely because item configuration diverges between locations ("Displays items that have any different values set between two locations. Must be run with two, and only two locations selected"); and Brink identity is per-location by design - the API FAQ states of employees that "Employee IDs are unique on a per-location basis... Pushing the same Employee IDs across multiple locations is not possible", with settings likewise retrieved per LocationToken. No master-item-ID mechanism spanning renamed or locally priced items is documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
The Admin Portal guide documents Gift Card Filters that "restrict the locations at which gift cards can be redeemed or applied," via a "Filter Locations: Limit gift card tendering by location" list — implying cross-location redemption is configurable when the filter spans multiple locations. Shortfall: no outstanding-liability-balance report or inter-store settlement/reconciliation mechanism between location owners is documented. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.
multi-location-cross-location-loyalty
Punchh is a brand-level loyalty platform with a single guest profile across the brand's locations (500M+ members claimed). https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/ · retrieved 2026-08-01
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
The Admin Portal guide documents Item "Brand Allocation": "Distribute sales of the item across more than one brand" by weighted percentage, with Product Mix reporting grouped by brand. Shortfall: this is a sales-attribution mechanism for accounting purposes, not documented support for two brands running separate menus, receipts/branding, and drawer-level revenue separation on one terminal. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.
multi-location-multi-tax-jurisdiction
Settings/Settings2 are per-location configuration services covering location-level setup; multiple simultaneous rates, prepared-food vs grocery rules and per-location exemptions are not documented. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01
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
The schema has no such field, on both surfaces. Settings.svc's LocationOptions type is the complete location configuration object exposed by the API and its fields are Address1, Address2, City, Country, Fax, Latitude, Longitude, Name, Phone, State, TimeZone and Zip - country and timezone but no currency and no locale. The string 'Currency' appears zero times across the entire dumped legacy Brink API portal (12 pages, 659 operation anchors, 1.75MB of text), including every money-bearing type in Sales2.svc and Ordering.svc, so order, payment and tender amounts carry no currency qualifier and there is nothing to convert. It appears zero times again in the 5.16r2 Admin Portal Configuration Guide (8,425 lines covering every Admin Portal and Settings Editor screen, including Location Groups, Taxes, Tenders and the Rounding options), whose only localisation feature is a UI toggle - "To Change the Administrator Portal to the French Language". Consolidated multi-location reporting exists (Comparative and Product Mix across location groups) but is arithmetic on unqualified amounts, with no reporting currency or conversion step documented. Scope note: this is Brink POS; PAR does sell internationally through other product lines. https://brinkapiportal.parpos.com/settings · retrieved 2026-08-08
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
Changeset Publisher/Changeset Packages record "Created By" (full name of the publishing user), "Created Time," per-changeset entity-level change detail (viewable by clicking the change count), and an exportable CSV of publish status per location — a queryable, corporate-visible record of who changed what and when. Shortfall: no explicit immutability guarantee is stated for the changeset log anywhere in the guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
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
The account settings screen is the entire configurable identity surface for above-store users, and it is local-only. The Admin Portal User configuration page enumerates: First Name, Last Name, Email Address, Alert Email Address, Mobile Number ("Used for Multi-Factor Authentication (if applicable)"), Username ("Username used for logging into the Admin Portal"), Password ("Password used to log into the Admin Portal"), Status Enabled/Disabled, "Account temporarily locked... automatically resets after 30 minutes", Force user to change password, "Email password on save: Generate an email to the user's email address that contains Admin Portal URL, username, and password", "Enable Multi-Factor Authentication: Place Holder for future development (MFA)", Limit Locations and Limit Roles. There is no identity-provider, federation or directory field, and even MFA is an unimplemented placeholder. Deprovisioning is manual - a user is set to Disabled, and the parallel employee model is explicit that records cannot be deleted, only overwritten or flagged Terminated. Across the 8,425-line guide, SAML, OIDC, SSO, 'single sign' and SCIM each appear zero times, as they do across the 659-operation legacy Brink API portal. Above-store access scoping is done instead by Roles ("Rights: Functions that are visible and allowed", plus Rank) and Location Groups. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
A business-level token exists alongside the location token, but PAR's own FAQ describes access failures caused by "unprovisioned API account access to specific locations," indicating per-location provisioning rather than one authenticated all-locations call. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01
Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.
multi-location-central-labor-policy
Overtime rules (Day Hours/Week Hours/Shift Hours/Day-In-Week, with a per-rule pay-rate Factor) are configured per location via Settings Editor, and the PAR OPS Autocompliance ScheduleRule/MealPeriodPenalty/MinorRule engines (already cited elsewhere in this record) are jurisdiction-scoped (country/state/county/city). Shortfall: rules are jurisdiction- or per-location-scoped, not organized as a "location group" hierarchy as the claim describes, and terminal-level enforcement is confirmed only for overtime — the Autocompliance break/minor/schedule rules enforce within the separately sold PAR OPS module, not documented as blocking at the POS terminal itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
PAR says its POS works with "many types of hardware you may already have," and PAR Volt runs Android or Windows — but no commodity iPad/Android tablet support is explicitly documented and PAR's pitch centers on its own terminals. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
Android and Windows named for PAR Volt; no minimum OS versions or device specs published. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
PAR Tablet: rugged, Gorilla Glass, sealed design, integrated NFC/RFID card processing. No published drop rating or IP ingress rating. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
PAR Tablet has no swappable battery; the 'yes' rests entirely on a marketing spec of "10-hour battery life" with no test standard or duty-cycle definition. (The swappable-module language on the hardware page belongs to PAR Volt compute modules, not batteries.) A vendor battery-life number is claim-level and should not clear a hot-swap bar. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01 adversarially verified
Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.
hardware-handheld-lte
The handheld's published connectivity list is enumerative and contains no cellular radio. The PAR Tablets specification table gives 'Connectivity Wi-Fi 6E, Bluetooth 5.3, LAN I/O docking station' — three named interfaces, no WWAN, no SIM, no LTE — alongside 'Sizes 8" and 10"', 'CPU Intel N100' and 'OS Windows 11 IoT Enterprise LTSC v24H2'. The PAR Volt data sheet (https://partech.com/wp-content/uploads/2026/08/PAR-Volt-Data-Sheet-080726.pdf, retrieved 2026-09-09) is narrower still, listing under Communication only 'Optional USB dongle available for WiFi support'. No vendor-supplied cellular failover is described anywhere. Absence control: 'LTE' and 'cellular' each occur ZERO times across all 1,358 documents (the single 'LTSC' token in the OS string does not match on a word boundary). Graded C rather than B because the enumeration lives on a product page written to sell, though the data sheet corroborates it. Bounded to a corpus frozen 2026-09-09: partech.com's WordPress REST API across all seven public content types (799 documents; the type registry at wp-json/wp/v2/types and the Yoast sitemap index reconcile — the only sitemap entries absent from the REST census are taxonomy archives), the 531-page developers.partech.com sitemap (which equals its llms.txt exactly, so that pair is one table rendered twice and is a FLOOR, not a census), and the 28 OpenAPI documents the per-section llms.txt files name. https://partech.com/solutions/pos-hardware/pos-tablets/ · retrieved 2026-09-09 automated extraction
Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).
hardware-offline-mode
PAR publishes offline behaviour and its limits in a dedicated document. Continued operation: "in the event of primary register failure, the backup register takes over, operating independently, without dependence on above-store/cloud services. This ensures seamless store operations even in the case of an internet outage"; the test procedure states that on killing the internet "the primary and all secondary registers will continue to function but in offline mode", and on losing the primary the backup primary "swiftly assumes control and continues operating in offline mode. The remaining secondary registers subsequently recover and also operate in offline mode". Single-register sites are covered too: "the primary register transitions to offline mode after a connection loss, as it currently does". The degradation list is explicit: "online ordering will not be available, as the backup primary does not currently support online orders", "If internet connectivity is lost, offline mode operates normally with the primary register acting as the host... However, online orders will still fail", and changeset publishing, the End of Day process and "synchronizing historical data to the cloud" are each stated as unavailable while the primary is down. It also names when offline mode does not work ("the primary and backup primary registers are both having a power loss or network failure"), and the 5.0n.r2/5.14 guardrails that block Clocking Out, Checking Out and Cash Drawer Assignment on the backup primary for a default 15 minutes. On recovery, "When the Primary connection reestablishes itself, it automatically initiates self-correction and resynchronizes with both the backup primary and the cloud server." Not covered by PAR's degradation list: card-authorization, loyalty-lookup and refund behaviour while offline are not addressed in this document. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
First-party KDS sold with a programmable bump bar and docking stations; PAR also exposes a Kitchen API service for queue and bump times. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
Kiosk offered with the same loyalty/ordering engine; countertop vs freestanding form factors and ADA conformance are not documented. https://partech.com/solutions/guest-engagement-platform/digital-experience/ · retrieved 2026-08-01
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
PAR sells drive-thru headsets (G5 audio), a Drive-Thru Timer for speed-of-service measurement, and integrates order confirmation boards. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
The Edit Printer dialog's General tab documents the Model drop-down list by name: "Epson TM-L90, NCR 7197, PAR M3876, Partner RP-320, Star TSP100, or Zebra TTP 2000" (which then expose Parity, Handshake, COM Port and BaudRate), and separately "Epson TM T88, Epson TM T88 ReStick, or Epson TM U200", which expose an Interface Type of "Ethernet: TCP/IP Address: Enter the IP address of the printer" or Serial. That is six manufacturers - Epson, NCR, PAR, Partner, Star and Zebra - so vendor-branded hardware is one option among many, and the Epson TM-T88 family is the standard ESC/POS thermal receipt printer, supported over LAN as well as serial. Kitchen use is a per-printer flag on the same dialog ("Is Kitchen: Can be included in printer groups", with Print All Items, Print Only Customized Items and Chit Type None/Summary/Single/Bag/Both). The API mirrors it: Settings2.svc's Printer type carries Model (PrinterModel), Interface ("Select one of the following: Ethernet, Serial, Windows"), BaudRate, ComPort, Parity, Handshake and IsKitchen. PAR also publishes a standalone Epson TM-L90 Label Printer Formatting Guide. The phrase 'ESC/POS' is not used in PAR's documentation; the manufacturer and model list is the evidence. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.
hardware-peripherals
Docking stations, printers and cash drawers named. No published compatibility list; scales, barcode scanners and customer-facing displays not confirmed. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
Card entry is on dedicated PIN pads, but PAR states neither a validated P2PE listing nor the merchant's SAQ type. The devices are named in PAR's own PAR Pay RMA guide - P400, Move 5000, Link 2500, Lane 3000, Lane 3600, Lane 7000, Lane 8000 - all Ingenico Tetra-family PIN pads rather than the POS tablet, and PAR publishes per-device setup guides for them plus a DataCap EMV payment matrix; the PAR Pay 2024 PCI Upgrade notice shows PAR pushing mandatory device firmware and warns that "failure to comply will result in your devices being unable to process transactions", with transactions routed to Aurus endpoints. What is missing is exactly what the claim demands. PAR's Software Security Framework FAQ says "ParTech will provide our most recent PA-DSS AOC for PAR POS as well as our Letter of Engagement from our third-party consultant to demonstrate our current efforts for PAR POS to be certified with SSF", and the attached Coalfire letter dated 18 Oct 2022 states only that PAR "has engaged Coalfire Systems, Inc. to perform a Secure Software Assessment in line with the PCI SSC P2PE requirements" with "The assessment is planned to conclude in early 2023" - an engagement, not a validated P2PE solution listing, and PAR has published no completion notice since. No PCI PTS listing is cited for any device by PAR, no claim is made that the POS application and tablet are out of PCI scope, and no merchant SAQ type is stated anywhere - the Network Connectivity guide instead pushes the question back to the customer: "PAR recommends reviewing all policy changes with your network security team and PCI auditors". https://cdn.parpos.com/docs/PARPOSSoftwareSecurityFrameworkFAQ.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
Contactless acceptance is documented as running on dedicated payment hardware, not on a commodity phone. The POS Peripherals page enumerates the payment path as 'Payment Devices Verifone terminals support most payment methods', and the PAR Tablets accessory list describes a 'Snap-on payment module' that 'enables convenient mobile checkouts' — i.e. a separate reader is the documented means of taking a tap on a tablet. Absence control: 'Tap to Pay on iPhone', 'Tap to Pay on Android' and 'tap to phone' each occur ZERO times across all 1,358 documents. 'tap to pay' occurs in 4 marketing documents, none of which is a Tap-to-Pay-on-device claim. Second citation: https://partech.com/solutions/pos-hardware/pos-tablets/ (retrieved 2026-09-09). Bounded to a corpus frozen 2026-09-09: partech.com's WordPress REST API across all seven public content types (799 documents; the type registry at wp-json/wp/v2/types and the Yoast sitemap index reconcile — the only sitemap entries absent from the REST census are taxonomy archives), the 531-page developers.partech.com sitemap (which equals its llms.txt exactly, so that pair is one table rendered twice and is a FLOOR, not a census), and the 28 OpenAPI documents the per-section llms.txt files name. https://partech.com/solutions/pos-hardware/pos-peripherals/ · retrieved 2026-09-09 automated extraction
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
No SKU-level prices anywhere on the hardware page; the page directs buyers to a demo or 1-800-382-6200. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-01
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
PAR states which, in an SEC filing. The 2025 Form 10-K's revenue recognition policy reads: "Hardware revenue consists of hardware product sales and is recognized as a point in time revenue. Revenue on these items is recognized when the customer obtains control of the asset in accordance with the terms of sale. This generally occurs upon delivery to a third-party carrier for onward delivery to customer. We accept returns for hardware sales and recognize them at the time of sale as a reduction to revenue based on historical experience." Title and control pass to the customer on delivery - a sale, not a rental. It is reported as a separate revenue stream from Subscription Service, whose SaaS fees are by contrast "recognized ratably over the contract period" on contracts "generally for a period ranging from 12 to 36 months", so hardware is not a subscription-bundled rental; hardware revenue was $106.4 million in 2025. The accompanying warranty policy confirms ownership economics - a warranty reserve is recorded "When a sale is consummated", over a warranty period that "can range from 12 to 60 months". Not established by this source: the retail purchase price of any device, or whether PAR or a reseller separately offers a financing or lease option alongside outright sale - partech.com publishes no hardware pricing or acquisition terms. https://partech.com/wp-content/uploads/2026/02/10-K-Document-2025.pdf · retrieved 2026-08-08
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
Every ingredient of the answer is now published and the conclusion itself still is not. PAR's Hardware Terms (v2.0, 11.14.25) state ownership outright - "For Hardware purchased by Customer, title will pass to Customer at delivery" - and pass the embedded operating-system licence through to the customer, incorporating the Microsoft EULA "located at Drivers and Downloads (partech.com) are all incorporated into and made a part of these Terms". That Drivers and Downloads library is public and un-gated (https://support.partech.com/documentation/, support.partech.com): 137 download entries enumerated from its sitemap, including per-model OPOS/UPOS device drivers for every current terminal line (Wave, Volt, Phase, Controller, Helix, EverServ, PAR Tablet) and the Windows 10 IoT Enterprise and Windows Embedded POSReady 7 operating-system entries, with no login and no customer account. OPOS/UnifiedPOS is the vendor-neutral driver standard third-party POS software uses, and the Remote Care Services terms show PAR itself deploying customer-supplied software onto the terminals: "ParTech will create procedures that allow for third-party software installation" - which is a live-subscription managed service, not a statement about the machine after cancellation. On exit, the Subscription Services Terms section 5 enumerate the customer's obligations - "Customer's right to access or use the ParTech Services, and Customer's license to the Licensed Software, shall immediately cease" and the customer must "uninstall the Licensed Software and follow any instructions set forth in the Documentation, and destroy or return all Documentation and all other" Confidential Information (https://partech.com/doc/01-subscription-services-terms/). Hardware is not in that list; the customer keeps the machine and removes PAR's software from it. Shortfall, and it is the whole reason this is not a yes: no PAR document states that a purchased terminal remains usable with another vendor's POS application after cancellation. The entitlement question is answered only by inference from title, the pass-through OS licence, the public driver library and the uninstall-not-return termination clause - and the same corpus cuts the other way once, in the PAR Pay 2024 PCI upgrade notice, where PAR can push firmware that leaves a payment device unable to process transactions. https://partech.com/doc/02-hardware-terms-for-master-agreement/ · retrieved 2026-09-12 adversarially verified
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
A turnaround SLA is published; a customer-facing warranty term is not. The PAR Pay RMA Quick Reference Guide sets out two tiers side by side: Standard RMA - "No contract required", "Get a replacement device shipped to the store within 3-4 business days after the Help Desk processes the RMA request", "Replacement fee: $200, billed to your account"; and Advanced Exchange RMA - "Contract required", "Get a replacement device shipped to the store within 2-3 business days", "No replacement fee". Both require the damaged unit back on a provided FedEx label within 10 business days or "you are billed the full price of the device plus a 15% fee", and eligible devices are enumerated (P400, Move 5000, Link 2500, Lane 3000/3600/7000/8000). The 2025 Form 10-K corroborates the programme at company level: "We offer depot repair, warranty, and overnight Advanced Exchange services", with hardware support revenue coming from "the Company's Advanced Exchange overnight hardware replacement program, on-site support, and extended warranty repair service programs". Shortfalls: the published turnaround SLA covers PAR Pay payment devices only - no equivalent is published for POS terminals, KDS units or printers; and no customer-facing warranty term is published for any product, the only figure PAR states being the 10-K's accounting range that a warranty period "can range from 12 to 60 months", which is a reserve-estimation range rather than a stated term. https://cdn.parpos.com/docs/PARPayRMAQRG.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
The vendor argues against BYOD explicitly. The PAR Tablets page opens its core-benefits section 'Not Just Any Tablet' with 'Consumer tablets belong at home. PAR point of sale tablets are engineered from the ground up to remain unstoppable through every ding, spill, and rush that foodservice throws at you.' The device is PAR-supplied and PAR-imaged — 'OS Windows 11 IoT Enterprise LTSC v24H2', 'IP65, drop tested up to 1.8m' — and no staff-personal-device mode, permission model or security model for one is published. Absence control: 'BYOD' and 'bring your own device' each occur ZERO times across all 1,358 documents. Bounded to a corpus frozen 2026-09-09: partech.com's WordPress REST API across all seven public content types (799 documents; the type registry at wp-json/wp/v2/types and the Yoast sitemap index reconcile — the only sitemap entries absent from the REST census are taxonomy archives), the 531-page developers.partech.com sitemap (which equals its llms.txt exactly, so that pair is one table rendered twice and is a FLOOR, not a census), and the 28 OpenAPI documents the per-section llms.txt files name. https://partech.com/solutions/pos-hardware/pos-tablets/ · retrieved 2026-09-09 automated extraction
Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator
hardware-remote-device-management
A device console exists and covers terminals and KDS, but not the rest of the claim. Admin Portal > Home > Devices "displays the connection status for all Kitchen Displays and Registers for the selected location", along with "the Terminal Topology, which is the configuration of the terminal e.g. IP Address, Machine ID"; "The status of the Maintenance Service for each Register and Kitchen Display is reported in the Maint. Svc. Status column"; the page also shows all cash drawers with who they are checked out to and their cash, and lets an admin change a location's environment type. Terminal Topology is where the backup primary register is elected for In-Store Resilience, and register displays are labelled with role and state ("Register 2 (BP) - Online"). Remote action is limited but real: Tools > Run End of Day "lets an Admin Portal user initiate the end of day process at a location remotely", and configuration is rolled out through Changeset Publisher, which targets selected locations or location groups either Immediately or at End of Day with per-location status, Retry and Download Errors. The API exposes one status probe, Ordering.svc GetMasterTerminalStatus, "to check whether the Primary Register of the location is online (connected to the cloud) or offline" (0 = Offline, 1 = Online). Shortfalls: printers are not shown on the Devices page - they are configuration objects only; there is no remote reboot; no software-version display per device is documented, and version state is handled by overnight patching (BMS patch applications requiring "Terminals should be powered on at all times"); and update rollout is not staged by ring or cohort - the only staging PAR documents is configuration changesets, and its own guidance is procedural ("Changes done in one location should not be cascaded ahead to more than a set of 500 locations"). https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Integrates with specialty beverage hardware — self-pour tap walls, flow meters, or liquor pour spouts — such that pours post to a POS tab automatically.
hardware-selfpour-scales
The peripheral catalogue is enumerated twice and contains no beverage hardware. The POS Peripherals page offers 'a complete line of industry-leading POS peripherals' and names six categories — PAR Printer, PAR Cash Drawer, PAR Compact Cash Drawer, Payment Devices, POS Docking Stations, Bump Bars. The PAR Peripherals data sheet (https://partech.com/wp-content/uploads/2026/06/PAR-Peripherals.pdf, retrieved 2026-09-09) independently lists only the Triple Interface PAR Printer, PAR Compact Cash Drawer and PAR Cash Drawer. No tap wall, flow meter, pour spout or scale appears in either. Absence control: 'self-pour', 'flow meter', 'pour spout', 'tap wall', 'keg', 'free-pour' and 'jigger' each occur ZERO times across all 1,358 documents AND across the eleven hardware PDFs read for this pass; 'weigh' occurs in 2 marketing blog posts, neither about beverage dispensing. ('sensor' is NOT a usable control here and was dropped on audit: it occurs once, in the KDS Bump Bar data sheet, describing a 'projected capacitive touch sensor'.) Caveat kept in the open: 'a complete line' is a sales page's framing of its own catalogue, so this is a strong floor rather than a contractual ceiling. Bounded to a corpus frozen 2026-09-09: partech.com's WordPress REST API across all seven public content types (799 documents; the type registry at wp-json/wp/v2/types and the Yoast sitemap index reconcile — the only sitemap entries absent from the REST census are taxonomy archives), the 531-page developers.partech.com sitemap (which equals its llms.txt exactly, so that pair is one table rendered twice and is a FLOOR, not a census), and the 28 OpenAPI documents the per-section llms.txt files name. https://partech.com/solutions/pos-hardware/pos-peripherals/ · retrieved 2026-09-09 automated extraction
Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.
hardware-callerid-integration
Caller ID hardware is supported and surfaces the call at the POS, but stops at name and number. Settings Editor > Options > System > Caller ID is a dedicated configuration tab: "Configuration settings for caller ID device, which communicates caller name and number to the POS when an incoming call is received. When enabled, displays caller name and phone number at the top of the 'Future Order' screen." The device is configured by Register ("Register that is caller ID device is physically connected to"), Model ("Make and model number of the caller ID device"), Interface ("Interface type of the caller ID device"), COM Port and Reverse Caller Name ("Displays the caller name as 'Last Name, First Name'") - a serial caller-ID unit attached to a named terminal, with the model left open rather than restricted to a PAR part. Shortfall: what pops is the inbound caller's name and number on the Future Order screen, not the matched customer record - PAR documents no lookup of the stored customer, no order history recall and no linkage to the Customers module or the Lookup Customer register button from an incoming call, and no telephony/VoIP integration is documented anywhere as an alternative route. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
Both the unified PAR Developer Portal and the legacy Brink API portal are readable with no login, NDA or sales call; OpenAPI documents, Postman collections and client libraries are downloadable. https://developers.partech.com/ · retrieved 2026-08-01
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
A separately-priced API tier exists and the base subscription is not shown to exclude API access - so this is limited, not absent. The 2026-09-12 sweep read the API Service Level Commitment (v2.0, 11.14.25) and took its opening scope - customers who "have elected to pay additional Fees based upon the number of Customer's eligible integrations to the PAR POS Services" - as a gate on API access. It is not one: it is the availability clause of that SLC, and the sibling document in the same published suite settles the point the other way. The base Service Level Commitment for PAR POS Services, which is available to every PAR POS subscriber with no fee election at all, commits to uptime for "an in-store point of sale transaction (i.e., open and close an order) using a point of sale terminal or using the in-store API" - so in-store API use sits inside the ordinary subscription. The same document also says of the above-store portal that "this Above-Store Admin. Portal Availability Service Level Commitment does not include API Services which are separately covered by the API Service Level Commitment", which is what the elected Fees buy: the above-store, third-party-integration API. Shortfall, and it is real. Above-store API access is a separately-feed subscription whose base is per named token - Eligible API Integrations is "the number of named API account tokens issued as instructed by Customer on Customer's behalf for an API integration to the PAR POS Services by Third-Party Services" - and both master contracts reserve a charge for direct use in the Licensed Software definition, which grants "any application programming interfaces (APIs) thereto" as part of the Licensed Software and then provides that "if Customer is directly using the API for any ParTech Services (not through a Third Party Service), Customer may be required to pay additional Fees to ParTech for the use of such API" (https://partech.com/doc/02-par_gen-subscription-services-agreement_website/, https://partech.com/doc/01-par-master-agreement-consolidated-all-par-services_website/). That is a reserved right to charge, in permissive terms, with no published amount; the per-location fee this claim names is nowhere documented, and neither is a plan-tier requirement. https://partech.com/wp-content/uploads/2026/02/08-Service-Level-Commitment-PAR-POS-Services-v2.0-2025-11-14.pdf · retrieved 2026-09-12 adversarially verified
A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator
extensibility-free-sandbox
Development/test servers exist (Brink dev server; Punchh sandbox base URLs), but the URLs and keys must be requested from a PAR/Punchh representative — no self-serve seeded sandbox. https://developers.partech.com/docs/dev-portal-pos/additional-topics/make-first-pos-call · retrieved 2026-08-01
Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).
extensibility-oauth-partner-apps
Verified at the source. The developer portal states the header format `Authorization: Token token=LOCATION_KEY_GOES_HERE, btoken=BUSINESS_KEY_GOES_HERE` and "If you do not have these keys, reach out to your Punchh representative." Sandbox and production base URLs must also be requested from a rep. Brink side is the same pattern: the FAQ tells you to email api.support@partech.com or call (800) 403-9027 for tokens, and diagnoses failures with "Are you provisioned to access this location with your API account's AccessToken?" Static tokens, per-location provisioning, no OAuth, no operator-granted https://developers.partech.com/docs/dev-portal-pos/additional-topics/make-first-pos-call · retrieved 2026-08-01 adversarially verified
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
Guest lifecycle webhooks are documented; order lifecycle events are not — PAR's own guidance is to poll GetOrders with a ModifiedTime filter. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01
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
Signed and retried with documented backoff; no replay of missed deliveries. The External Orders API 2.0 webhook contract defines an X-Webhook-Signature header, in the form sha256=<hex>, described as 'HMAC-SHA256 of the raw JSON body using your' webhook_signing_secret, and pairs it with an X-Idempotency-Key described as 'unique per delivery attempt; use for deduplication' (both descriptions sit in cells of a two-column Markdown table, so each is quoted only within its own cell), and specifies 'Retry: One synchronous attempt, then up to 5 queued retries with exponential backoff (1s, 2s, 4s, 8s, 16s). Respond with 2xx to acknowledge.' The Punchh Webhooks Manager documents a second, separate schedule: retry 3 times at 15, 45 and 180 second intervals on HTTP 429 and 408; 7 times at 60, 120, 300, 600, 1800, 3600 and 7200 second intervals on HTTP 500; 3xx treated as failure and not retried; and a circuit breaker that suspends an event once the failure counter 'goes over 1000', reactivated by a successful response to a ping webhook. Shortfall — the third limb of this claim fails: no replayable event log is published. Punchh states log retention is bounded ('No logs are available after 7 days') and that reactivation revokes suspension rather than redelivering missed events, and neither API documents a replay or redrive endpoint. Punchh also disclaims ordering outright: it 'does not guarantee the delivery of events in the sequence in which they were created' and 'may publish some messages at least once', so consumers must be idempotent. Second citation: https://developers.partech.com/docs/dev-portal-webhooks-manager/webhook-delivery (retrieved 2026-09-09). https://developers.partech.com/docs/eo-api/apis/external-orders-api-2 · retrieved 2026-09-09 automated extraction
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
A dedicated Ordering service (api2.brinkpos.net/Ordering.svc) creates orders as POS transactions; DPIP membership requires those injected orders to behave as first-class tickets. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01
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
Asymmetric. Items, modifier groups and prices are writable; menu structure, kitchen and much of sales/labor are read-only. Not every readable object is writable. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-01
API rate limits are published as specific numeric quotas with documented throttling behavior and headers.
extensibility-published-rate-limits
Verified verbatim: "5 concurrent calls with a sleep of 2-3 minutes in between calls" (multi-tenant) vs "10 concurrent calls with a sleep of at least 1 minute" (single-tenant); save batches capped at 100 and delete batches at 20, "RPM should not be more than 5 requests per minute." Guidance, not enforced quota semantics — partial is correct. https://brinkapiportal.parpos.com/bestpracticeandfaqs · retrieved 2026-08-01 adversarially verified
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
DoorDash publishes its own complete provider registry at https://merchants.doordash.com/api/partner-integrations — 64 providers, each carrying a `qualityStatus` of PREFERRED (12), CERTIFIED (47) or AT_RISK_OF_SUSPENSION (5), plus a features-completed count against the eight high-quality features the program requires. It is served anonymously and merchants.doordash.com/robots.txt permits it (Allow: / with only /cdn-cgi/ and /monitoring barred). This is the instrument the program page points to when it says the roster is tracked in real time, and it supersedes the 2026 announcement post most of this corpus cited — that post introduces its ten names with the word `include`, which makes it a floor, not a ceiling. In that registry this vendor is the entry `partech_menu_production`, rendered as 'PAR', with qualityStatus PREFERRED and 8 of the 8 high-quality features built. 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
DoorDash direct and certified. Uber Eats and Grubhub connectivity is claimed on PAR's delivery-operations page, but that product is reconciliation/dispute recovery — first-party certified order integrations for all three are not separately documented. https://partech.com/solutions/insights-and-delivery-solutions/ · 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
PAR's 291-partner public directory covers aggregation middleware categories, and Deliverect/Chowly-class platforms broadly list Brink as a supported POS — but individual middleware endpoints were not verified vendor-side in this pass. https://partech.com/partner-ecosystem/ · retrieved 2026-08-01
Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.
extensibility-accounting-connectors
Restaurant365 maintains a PAR partner integration and PAR's directory spans accounting/BOH categories; a vendor-maintained QuickBooks Online connector with mapped journal entries is not documented. https://partech.com/partner-ecosystem/ · 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 defect — scored against the partner directory. A bare "Payroll export" bullet supports partial at best. https://partech.com/solutions/back-office-solutions/restaurant-labor-management-scheduling-software/ · 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
No scheduled push to a customer-controlled destination exists. The Admin Portal's export capability is stated as a closed set - "The Export section provides tools for exporting customers, sales, labor, settings, and surveys" - and every one of the five produces a file for the user to download: Customers is "a CSV file for download", Sales "a file that can be imported into a third-party accounting or inventory system" shaped by the GL Export account mapping, Labor "a file that can be imported into a third-party payroll system", Settings "a CSV file" of which "Currently, only items can be exported", Surveys a CSV of responses. The only recurring automated delivery in the product is Scheduled Reports, which sends "Reports that are to be generated and attached as PDFs to the email" at End of Day or a specific time - finished reports by email, not raw rows to a destination. FTP, SFTP, S3, Snowflake, BigQuery and 'warehouse' appear nowhere in the 8,425-line configuration guide. The transaction API confirms it from the other direction: Sales2.svc GetOrders takes one BusinessDate, only three calls in the whole API accept a date range, and PAR's guidance for continuous data is to poll - "Live dashboarding or live data calls include: GetOrders in Sales2.svc - using the ModifiedTime field", at 5-10 concurrent calls with a 2-3 minute sleep. Scope note: PAR sells Delaget and PAR Intelligence as separate analytics products; this is a finding about Brink POS itself. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
A public, filterable partner directory of 291 named integrations exists and is browsable without login — but there is no self-install flow; partners are sales-mediated. https://partech.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
The Admin Portal guide documents "Custom Fields" (Admin Portal > Configuration > Custom Fields): an operator adds a new field via "+ New Field," then applies it to Items/Promotions with no vendor engineering engagement. Separately, "Script Functions are VB Script functions that can be called via the 'Execute Script' button behavior," configured directly in Settings Editor and documented further in a companion "PAR POS Register Scripting" guide. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.
extensibility-headless-embedded
PAR markets "Build a custom POS experience with PAR POS" APIs plus an order-injection service, which supports a headless pattern; no formal headless/embedded mode is documented. https://developers.partech.com/ · retrieved 2026-08-01
The vendor publishes an API changelog and a stated deprecation/notice policy for breaking changes.
extensibility-api-versioning-deprecation
The legacy portal states the old API portal has moved and "will eventually be deprecated," and WSDL versioning is described — but no changelog and no stated notice period for breaking changes were found. https://brinkapiportal.parpos.com/ · retrieved 2026-08-01
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
Some of the data is exportable on demand in documented formats; the transaction record and the exit guarantee are not. What the operator can self-serve, from the Admin Portal Export section: Customers ("produces a CSV file for download" with filters on birthday, gender, communication preferences, order date, items ordered, surveys taken, preferred and signup location, signup date, email address and zip), Settings ("a CSV file containing records of the selected settings type", but "Currently, only items can be exported"), Labor ("a file that can be imported into a third-party payroll system") and Sales ("a file that can be imported into a third-party accounting or inventory system", formatted from the GL Export account mapping - QuickBooks IIF is the worked example). Shortfalls: order-level and payment-level detail is not in that list at all - it is reachable only through Sales2.svc GetOrders, one business date per call, under a rate-limit guidance of 5 concurrent calls with a 2-3 minute sleep, using an AccessToken and LocationToken that PAR provisions per location and that would presumably lapse with the contract; the Sales export is GL-summarised rather than transaction-level; menu export covers items only, not modifier groups, panels or promotions; and neither the Admin Portal guide, the API portal nor partech.com states any post-termination retrieval window, data-ownership clause or exit-export commitment. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
Testing and Validation, step 2: 'Turn off the internet connection. a. This will be your DSL or cable modem. b. The primary and all secondary registers will continue to function but in offline mode, just as they currently do.' The FAQ repeats it: 'If internet connectivity is lost, offline mode operates normally with the primary register acting as the host as it does today (prior to 5.0m).' The 5.16r2 Admin Portal guide carries the matching register-side UI: 'Show Offline Indicator: Displays "Offline" at the top of the panel on the Register when the connection status of the current register is offline.' Ticket routing rides the same local host (see this record's reliability-offline-kds-printing). What does not survive an outage is the cloud-dependent work: online orders still fail, and changeset publishing and End of Day are unavailable. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
Subscription Services Agreement (v2.0, 11.14.25) section 6.a, 'PAR Pay Services Supplemental Terms - Store and Forward Functionality': 'The PAR Pay Services offer functionality that enables Transaction Data to be stored in a payment device in the event the payment device's connection to the processor is lost, and to forward the Transaction Data upon reconnection with the processor (commonly known as "Store and Forward" or "SAF" functionality). Customer may, in its discretion, enable SAF functionality and set available parameters for number and value of Transactions that may be stored.' The fees clause (13.c) confirms it operationally, defining a billable Transaction to include 'offline/store and forward requests'. A second, manual offline path also exists: the 5.16r2 Admin Portal guide's 'Force Authorization' permission lets an employee 'select the Voice button on the "Credit Card" payment dialog used for offline credit authorizations'. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · 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
Subscription Services Agreement section 6.a states the liability allocation explicitly: 'In the event that SAF Transaction Data stored in a payment device is not forwarded to the processor as desired, Customer may request that ParTech attempt to recover the SAF Transactions... provided that ParTech does not represent or warrant that recovery (in whole or in part) is possible or will be successful. Any SAF recovery efforts by ParTech will be chargeable on a time and material basis... ParTech disclaims, and Customer releases ParTech from, any liability resulting from Customer's election to enable SAF functionality or ParTech's SAF recovery efforts.' Named shortfall: the cap is described as a capability but never quantified - 'Customer may... set available parameters for number and value of Transactions that may be stored' - and no default, ceiling or per-transaction limit is published in the agreement, the PAR Pay EMV Setup Guide, or the 5.16r2 Admin Portal guide. Who bears the loss is answered (the merchant, in full); the numeric offline cap is not. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · 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
The release notes enumerate the outage cases. Example 3, 'Both Primary Register and Above-Store Services Offline': previously 'Secondary Registers are Down with no Connection'; from 5.0m, 'Secondary Registers Connect to Backup Primary Register (No Interruption)'. With only the internet down, the FAQ says 'offline mode operates normally with the primary register acting as the host'. That the state is shared over the LAN rather than islanded is proved by the contrasting case: 'What happens if the local area network (LAN) or switch in the store experiences an outage? A: The primary and backup primary registers will both operate independently in offline mode. Meanwhile, the remaining secondary registers will show an error message stating "Waiting for connection to server".' The 5.0m fix list names the shared-order failure mode directly: 'synchronization failures occurred due to multiple registers editing the same order'. Limits during host failover: Clocking Out, Checking Out and Cash Drawer Assignment are blocked on the Backup Primary for a configurable 15 minutes. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
PAR publishes an on-premise Primary Register in the ordering path, on a host that permits us. The Ordering service's own OpenAPI document exposes the operation GetMasterTerminalStatus, described as 'Check whether the Primary Register of the location is online (connected to the cloud) or offline.' Two things follow from that one sentence: the location has a designated Primary Register distinct from the cloud, and its cloud connectivity is a separately queryable state rather than a precondition of the service existing. The SOAP service index states the same in prose — 'Additionally there is a GetMasterTerminalStatus call which checks that the Primary Register is online' — and the Ordering service overview lists 'master terminal status checks' among its capabilities alongside order submission, tender application and kitchen instructions, so the check sits inside the ordering contract rather than beside it. Endpoint shape corroborates the on-premise siting: every Ordering.svc server entry is templated per tenant as https://{server_name_goes_here}.parpos.com/Ordering.svc. Shortfall not claimed away: this establishes that a local Primary Register exists and is addressed by the ordering path; it does not by itself document the local engine's storage or failover mechanics, which PAR describes only in the barred cdn.parpos.com architecture FAQ and, at marketing grade, in its Spring Release post (https://partech.com/2024/07/03/elevate-your-dining-experience-discover-the-power-of-par-brinks-spring-release/, retrieved 2026-09-09): 'if a primary register loses connection to the cloud, a designated backup register will take over and conduct in-store operations independently of the cloud.' https://developers.partech.com/docs/parpos-cloud-apis/soap/ordering · retrieved 2026-09-09 automated extraction
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
The In-Store Resilience release notes state that on complete internet loss 'offline mode operates normally with the primary register acting as the host' — in-store operation is hosted on the local primary (or backup primary) register, not the cloud. Kitchen terminals are explicitly part of the local terminal topology (named as ineligible to serve as backup primary), and kitchen printers are configured as attached to specific registers (5.16r2 Admin Portal guide), so kitchen routing rides the local host. The doc does not narrate KDS behavior offline device-by-device; what it documents is that the entire in-store device set continues normal operation with local hosting. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read
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
Settings2 documents backup printing as first-class configuration: Printer carries BackupPrinterId ("Id of the BackupPrinter") and PrinterGroup carries RoutingOverrides (PrinterGroupRoutingOverride objects with Type and alternate Printers). Shortfalls: the automatic failover trigger (detection of an unreachable printer) and any staff alert on reroute are not described in public documentation — only the configuration fields are. https://brinkapiportal.parpos.com/settings2 · retrieved 2026-08-03
The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).
reliability-sync-conflict-handling
The In-Store Resilience release notes document partition behavior explicitly: a configurable 15-minute guardrail blocks Clocking Out, Checking Out and Cash Drawer Assignment on the Backup Primary after it starts hosting 'to decrease the frequency of state synchronization issues'; on reconnect the primary 'automatically initiates self-correction and resynchronizes with both the backup primary and the cloud server'; and the 5.0m changelog acknowledges sync failures caused by 'multiple registers editing the same order' with an added prevention layer. Shortfall: the resolution rule for concurrent edits that do occur — last-write-wins, merge, or operator prompt — is never stated; prevention guardrails and automatic resync are documented, the conflict-resolution policy itself is not. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read
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
OVERTURNED from `no`, and the record already contradicted itself: the document that carries this is quoted by SIX sibling cells in this same record, one of which (labor-offline-time-punch) describes exactly the enumeration the prior rationale said did not exist. PAR does publish what stops when a store goes offline, in the In-Store Resilience release notes (Rev 05, June 2025). Named exclusions, all of them already recorded in this record from its 2026-08-08 read: three actions blocked on the Backup Primary for a default fifteen minutes after it takes over -- "Clocking Out", "Checking Out" and "Cash Drawer Assignment"; online ordering, since offline mode runs with the primary register as host but "online orders will still fail"; and, on a LAN or switch outage, the remaining secondary registers, which show "Waiting for connection to server". `partial`, not `yes`: it is a resilience release note rather than a systematic matrix, and none of the four functions the claim names -- gift cards, loyalty lookup, refunds, manual card entry -- is placed on either side of the line. NO URL, DELIBERATELY: cdn.parpos.com is a barred host (robots.txt `Disallow: /` for `*`, read 2026-08-16, data/robots-bars.json), so this cell is scored the same way as its six siblings -- grade C on a reading the record made before the bar, attributed rather than re-made here. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
Verified live: exactly two components (PAR PAY WALLET API, 'Merchent Service Portal' — sic), 100.0% 90-day uptime, 14-day incident history, all operational as of 2026-08-01. Payments only; no POS/Ordering/Punchh status page exists. https://status.parpay.partech.com/ · retrieved 2026-08-01 adversarially verified
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
Service Level Commitment - PAR POS Services (v2.0, 11.14.25), published openly at partech.com/terms-and-conditions/ and incorporated into the Subscription Services Agreement by section 5.b. Two commitments: 'ParTech shall achieve an In-Store Transaction Service Level Commitment of at least 99.8% at each Participating Location... in each Measurement Period' (a calendar month, 24x7 base hours, an In-Store Transaction defined as opening and closing an order on a point of sale terminal or the in-store API), and an Above-Store Admin Portal Availability commitment 'of at least 98.8% in aggregate across all Participating Locations'. Credit schedule for in-store: 99.5-99.79% = 10% of the monthly subscription Fee, 99.0-99.49% = 25%, 98.0-98.99% = 50%, 97.99% or less = 75%; admin portal: 10/25/50%. Read the fine print: in-store Downtime is measured from the creation of a support case rather than by PAR's own monitoring, credits are waived if no case was opened within 15 days of month end, credits cap at 100% of the month's fee, and no credit accrues while invoices are 45 or more days past due. This contract, not the '99.99% uptime' figure on the Cloud POS marketing page, is the SLA. https://partech.com/wp-content/uploads/2026/02/08-Service-Level-Commitment-PAR-POS-Services-v2.0-2025-11-14.pdf · retrieved 2026-08-08
The vendor publishes written post-incident reports or root-cause summaries for major outages.
reliability-incident-postmortems
The Service Level Commitment names https://status.parpos.com as the PAR POS Status Page. It is an Atlassian Statuspage created 2018-08-13 with per-stack components (PAR POS on Admin1 through Admin25) and, via its api/v2/incidents.json, 50 incident threads reaching back to 2024-09. Resolution updates do state causes in a sentence or two: 'Due to an external issue on the funding side, certain Merchant IDs experienced a shortage in deposits on June 26th, 2026'; 'This issue has been identified to be due to a release that OLO made today'; 'a degradation in service due to an AWS outage'; 'Due to an internal calculation error on our end, certain monthly processing fees may have been undercharged'. Named shortfall: no written post-incident report or root-cause document is published for any incident. The clearest illustration is the 2026-06-16 'Scooters: Terminal boot loop' entry, closed with 'The issue has resolved and an RCA is being investigated to determine the casue' [sic] and no RCA ever posted. What exists is cause attribution inside an incident thread, not postmortems. https://status.parpos.com/ · retrieved 2026-08-08
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
Technical Support Services Terms - PAR POS Services and PAR Pay Services (v2.0, 11.14.25), section 2.a: 'ParTech will provide Technical Support Service Representatives to respond directly to Customer Branded Restaurants available 24 hours a day, 7 days a week, 365 days a year for requests for Technical Support Services either via telephone, email, or self-service portal.' Two named shortfalls. (1) It is not documented as included in the base subscription: Subscription Services Agreement section 5.a makes technical support 'Subject to Customer's payment of the applicable Fees', and section 13.a lists 'support fees' as a Fee category separate from subscription service fees. (2) Customers who route through their own IT helpdesk get materially less: section 2.b limits Peer-to-Peer IT Group support to 7 AM - 8 PM Eastern Monday to Friday and 9 AM - 5 PM Eastern Saturday and Sunday, with representatives 'available by pager after hours' for Priority 1 issues only. The only phone response target published - 90% of synchronous contacts answered within 15 minutes - is expressly business hours only. https://partech.com/wp-content/uploads/2026/02/12-Technical-Support-Services-PAR-POS-Services-v2.0-2025-11-14.pdf · retrieved 2026-08-08
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
PAR claims on-time opening rates approaching 99% on multi-location rollouts, implying a field deployment organization; on-site install as a named, purchasable service is not documented. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
Terms of Hardware Sale (US and Canada) (Equipment, Installation and AE Services), v2.0, 11.14.25, section 5: 'ParTech will provide the Advance Exchange Services (the "AE Services") as to the purchased Hardware identified and set forth in the Order... for a period of one (1) year or three (3) years, as elected by Customer... During the AE Services Period, ParTech will provide 24/7 support, tracking and dispatch services and fully operational replacement Hardware', and the turnaround is stated: 'ParTech will ship replacement Hardware to Customer's ship-to address, freight prepaid, with next day delivery within the United States for requests received prior to 3:00 p.m. (Eastern Time), Monday through Friday.' Defective units return on a prepaid label and must be back within 14 days or the customer buys the replacement at full price plus a 20% restocking fee; ten ParTech holidays are excluded. Payment devices get a maintained spare pool ('PD AE Pool'), its cost included in the AE price. Baseline warranty without AE is a 30-day Out of Box Failure Warranty Period and a one-year Depot Warranty Period. A parallel, non-contract program covers payment terminals: the PAR Pay RMA Quick Reference Guide gives Standard RMA at 3-4 business days with a $200 replacement fee and Advanced Exchange RMA (contract required) at 2-3 business days with no fee. https://partech.com/wp-content/uploads/2026/02/03-Terms-and-Conditions_Sale_-Hardware-Installation-AE-Services-On-Site-v2.0-2025-11-14.pdf · 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
The In-Store Resilience release notes document the local backup as an operator-editable setting: 'Extended Local Register Database Backup to 30 Days [BRNK-33562 and BRNK-34355]. Adds the ability to configure the retention period of the local register.sdf during the End of Day process in the register.exe.config file... Default = 30 days (previously 5 days), Max = 30 days, Minimum = 7 days', with step-by-step instructions to edit BackupRetentionPeriodInDays in c:\brink\pos\register.exe.config. The Admin Portal separately offers self-service CSV exports of customers, sales, labor, settings and surveys (5.16r2 guide, Export section). Named shortfalls: the retention change exists for PAR's own support workflow ('customers reported missing data on support calls... the backup data on the system has often already been purged'), restore is nowhere an operator-facing function in the Admin Portal guide, and no RPO or RTO figure is published - the Security Overview (v2.0, 11.14.25) commits only that ParTech will 'perform regular backups sufficient to restore services to Customer within a commercially reasonable period of time' (3.7(i)) and to a business continuity plan tested at least annually with an attestation on written request (5.2). https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
trust.partech.com (found via the footer of partech.com/terms-of-use/) is a live trust center carrying compliance badges for PCI DSS, PCI SSF, SOC 2, CIS Controls 8.1, NIST CSF, GDPR, CCPA, PIPEDA, EU-US DPF and RH-ISAC, and its document index names a 'PCI DSS v4.0.1' artifact alongside 'SOC 2 Type 2', 'SOC 2 Type 1' and 'SOC 1 Type 2'. Named shortfalls: the version-named artifact is access-gated, not a published AoC - nothing is downloadable from the public page; the public PCI text is non-committal ('PAR follows industry expectations for securely handling payment-related information in alignment with applicable PCI DSS requirements'), naming no product scope, no assessor and no date; and there is no validated P2PE listing and no SAQ type anywhere on the site. The only PCI artifact PAR has ever published in full is the PAR POS Software Security Framework FAQ, which is stale - dated 18 Oct 2022, it offers 'our most recent PA-DSS AOC' plus a Coalfire letter of engagement for an SSF assessment 'planned to conclude in early 2023', and PA-DSS was retired on 28 Oct 2022. https://trust.partech.com/ · retrieved 2026-08-08
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Role-based permissions are extensively documented (SecurityLevel's 26+ discrete booleans, already cited elsewhere in this record), and the two halves of the claim diverge on the authentication side. At the register there is a real second factor: "Secondary Authentication PIN: Additional layer of security for employee register access. Must be a three to 12-digit numeric PIN", set per employee in the Register Access section alongside PIN, Card Number and Finger, and exposed on the API's Employee type as SecondaryAuthPin. On back-office Admin Portal accounts there is none - the User configuration page offers only "Mobile Number: Used for Multi-Factor Authentication (if applicable)" and "Enable Multi-Factor Authentication: Place Holder for future development (MFA)". So MFA is enforceable on POS logins but not on the back office, which is the half that matters most for an above-store administrator. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read 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
The Admin Portal guide documents a Training Mode at the register/kitchen level: "Indicate Training Mode on Kitchen Chits: Automatically prints 'Training Order' and 'Do Not Make' on kitchen chits while training to prevent waste." Shortfall: no public, free video/LMS training library was found; partech.com/solutions/cloud-pos/ only claims "Train employees... in under 30 minutes" without naming a library. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
The In-Store Resilience release notes document automatic failover to a pre-elected "Backup Primary" register: on primary-register network loss, the backup "swiftly assumes control and continues operating in offline mode" without manual intervention. The backup is auto-elected among eligible secondary registers the first time the feature is enabled (or manually pinned via BackupPrimaryTerminalNumber). Shortfall: not literally any terminal — only registers not marked "Exclude from Topology" are eligible, and kitchen terminals are separately documented elsewhere in this record as ineligible — so it is a single pre-designated backup rather than dynamic per-failure election among all terminals. https://cdn.parpos.com/release-notes/In-StoreResilienceReleaseNotes.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
PAR POS System Requirements (updated 4/1/26), Internet section: '1. Broadband class of connection: a. "Always on" connection at minimum speeds of 10Mbit/s down 10Mbit/s; b. 100 Millisecond Minimum Latency; c. 3G/4G/LTE only viable as backup solution.' Cellular is therefore supported and named as a backup connection for the store's WAN. Named shortfalls: it is the operator's own backup link rather than first-party hardware - no PAR terminal is documented with an LTE modem - and nothing describes automatic failover. PAR POS Network Connectivity Requirements (rev 4/9/2026), the definitive connectivity document, sets out three connectivity Options (wildcard DNS, static IP list, customer-maintained AWS IP blocks) and never mentions cellular, failover behaviour or a cutover trigger; the In-Store Resilience release notes' Feature Optimization table says only 'Only high speed internet should be used' and frames the WAN as 'your DSL or cable modem'. https://cdn.parpos.com/docs/POSSystemRequirements.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
Commercial, compliance & data ownership
Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator
commercial-month-to-month-contract
Subscription Services Agreement (v2.0, 11.14.25) section 12.a: 'Unless a different term is agreed to by Customer pursuant to an Order or a Pricing Addendum to this Agreement, the term of this Agreement will commence on the Effective Date and continue for a period of three (3) years ("Initial Term"), automatically renewing for successive periods of one (1) year at a time.' Section 2.a adds 'All Orders are non-cancellable by Customer' and 13.c 'all Fees and payments are nonrefundable'. The payment side matches: PAR Payment Services Terms section 8.1, 'These Terms will remain in effect for a period of three (3) years ("Initial Term") and will renew for successive twelve (12) month periods.' PAR's published standard agreements are its public offer, and that offer is a three-year term with one-year renewals; no month-to-month tier appears in any of the fifteen contract documents at partech.com/terms-and-conditions/. A shorter term is possible only by individual negotiation on an Order or Pricing Addendum, which is not a public offer. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08
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
PAR Payment Services (PPS) Terms and Conditions (v2.0, 11.14.25), section 8.2 'Termination for Convenience': 'Subject to payment of the Early Termination Fee set forth herein, Merchant may terminate this Agreement by closing its PPS Account and sending at least thirty (30) days advance written notice to PPS of such closure. Merchant shall incur and pay an early termination fee equal to the Merchant's estimated Monthly Transaction Volume as set forth in the Application multiplied by the Fees, as identified in Schedule 1, excluding any network, interchange, assessment and related Acquirer processing Fees and charges, for each MID under these Terms multiplied by each month for the remainder of the then-current term ("Early Termination Fee"). Merchant acknowledges that the Early Termination Fee is not a penalty, but rather a reasonable estimate of the damages PPS sustained because of Merchant's termination of the Agreement before the end of the Initial Term and any Renewal Term.' That is liquidated damages, named as such. The software side is harder still: the Subscription Services Agreement provides no customer termination-for-convenience right of any kind - section 12.b allows termination only for uncured material breach or insolvency - and 2.a states 'All Orders are non-cancellable by Customer'. One narrow escape exists and is scored separately at commercial-rate-increase-clause: the ETF is waived where the merchant exits in response to a fee change. https://partech.com/doc/04-sub-merchant-agreement_stand-alone/ · retrieved 2026-08-08
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
Subscription Services Agreement (v2.0, 11.14.25) section 12.a, published at partech.com/terms-and-conditions/ with no login or gate: the agreement runs three years and continues 'automatically renewing for successive periods of one (1) year at a time (each a "Renewal Term"), unless and until Customer provides written notice of cancellation to ParTech at least 30 days prior to the first day of any Renewal Term'. Both elements the claim requires are stated - the auto-renewal term (one year) and the cancellation notice window (30 days before the renewal date). The payment side is published too: PPS Terms section 8.1 (three-year initial term, successive twelve-month renewals) with 8.2 requiring 30 days' advance written notice to close the account. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08
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
PAR's EMV Card Processor Configuration Guide carries a "Features Matrix for PAR Certified Configurations" listing seven gateways, only one of which is PAR's: Datacap US EMV, Datacap Canadian EMV (Mercury NETePay / Vantiv Integrated Payments), PAX POSLink (Heartland Portico), Tender Retail Merchant Connect Multi (Chase Paymentech), VeriFone Point Classic (Vantiv), VeriFone Point Enterprise (First Data), alongside PAR Pay. The 5.16r2 Admin Portal User Guide separately documents Options > Payment > Credit Processor: "Processor Type: When you select a processor in this drop-down list, an Edit dialog is displayed. The information that must go into the fields on this dialog is provided to you by the credit processor" (Heartland shown as the example). Shortfall of the evidence, not the capability: PAR publishes no rate card, so processing is unbundled but unpriced, and PAR Pay-only features (tokenization, virtual terminal, quick chip, store-and-forward on some rivals) are listed as exclusive to PAR's own gateway. https://cdn.parpos.com/docs/EMV%20Card%20Processor%20Config%20Guide.pdf · retrieved 2026-08-06 · not refetchable · site policy · graded B when read adversarially verified
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
No interchange-plus markup, bps figure, or per-transaction rate published anywhere. Not documented publicly. https://partech.com/solutions/payment-services/ · retrieved 2026-08-01
The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator
commercial-rate-increase-clause
PAR Payment Services (PPS) Terms and Conditions (v2.0, 11.14.25) section 3.1: 'We reserve the right to change our fees with at least thirty (30) days advance notice. By continuing to use the Services, you consent to the change in Fees. To withdraw your consent, you must close your Account and provide us with written notice prior to the effective date of such change in Fees. If you do not accept the change in Fees and withdraw your consent prior to the expiration of the Initial Term of this Agreement or any Renewal Term, you will be deemed to have terminated these Terms for convenience under Section 8.2 below; provided however, the Early Termination Fee in Section 8.2 will not apply.' That is the penalty-free exit the claim asks for, and it is the second of the two limbs - the increase itself is not capped, only noticed, and the merchant must close the account before the effective date to use it. Worth contrasting with the software side, which has no equivalent: Subscription Services Agreement 13.b escalates fees at each Renewal Term automatically by 'the applicable annual percentage increase in the Consumer Price Index (CPI) over the prior 12-month period plus two percent (2%)', and reserves ParTech's right to exceed even that on 60 days' written notice, with no exit right attached. https://partech.com/doc/04-sub-merchant-agreement_stand-alone/ · retrieved 2026-08-08
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
partech.com has no pricing page and no dollar figures for software or terminals; every path is "schedule a demo." The "$90/month + $50 per terminal" figure circulating on aggregators is not PAR-sourced. https://partech.com/solutions/cloud-pos/ · 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
PAR OPS is described as offering "modular pricing options" and PAR sells POS, Ordering, Punchh, OPS and Payments as distinct products — but independent cancellation without repricing the base POS is not documented. https://partech.com/solutions/back-office-solutions/ · 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
PAR designs and sells its own terminals, KDS and peripherals — hardware product revenue is reported line-item in its earnings releases, so outright purchase is the business model, and no mandatory hardware lease is published either way. Shortfall: no published prices — the PAR Hardware page (re-checked 2026-08-04) lists no dollar figures and no acquisition terms at all (purchase, lease or hardware-as-a-service); every path routes to 'Schedule a Demo', consistent with partech.com publishing no pricing anywhere. https://partech.com/solutions/pos-hardware/ · retrieved 2026-08-04
Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator
commercial-hardware-not-locked
PAR states the POS works with "many types of hardware you may already have" and PAR Volt runs Android or Windows; no specific non-proprietary device or printer is named. https://partech.com/solutions/cloud-pos/ · 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
Upheld and cited. PAR does publish a services catalogue and implementation is in it -- the Services page names "Loyalty program implementation and onboarding", "Platform configuration & QA support (Execution Specialists)" and role-based onboarding among its Cloud Services -- but the page carries no currency figure of any kind (zero `$` matches in 9,603 stripped characters) and routes to Book a Demo. The companion Field Services Hourly page, whose title promises a rate, is a lead-capture form: "You're currently using break/fix service. Contract coverage helps reduce downtime" over a Request Coverage Information form, again with zero `$` figures. A full census of partech.com's WordPress sitemap index on 2026-09-09 -- 736 URLs -- contains no pricing page at all. So implementation, installation and training are a named, chargeable category priced only in the bilateral agreement, and none of it is $0 either. Grade C: a vendor services page. https://partech.com/services/ · retrieved 2026-09-09
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
Orders, sales, labor and settings are all pullable via documented APIs, but the API account and its per-location access must be provisioned by PAR — so it is API-available, not truly self-serve. https://brinkapiportal.parpos.com/bestpracticeandfaqs · 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
Citation re-pointed and evidence strengthened 2026-08-09. Machine-readable guest data is genuinely reachable by the operator: the Webhooks Manager guest event streams create/update/delete of the full guest record as JSON (email, phone, name, address, birthday, signup_channel, marketing_email_subscription, marketing_pn_subscription, sms_subscription, favourite_store_numbers, up to 25 custom profile fields, joined_at/last_activity_at); GET /api2/dashboard/users/info returns an individual guest's profile plus the loyalty balance object (points_balance, banked_rewards, net_balance, total_credits/debits, membership_level) and unredeemed reward ledger; and POST /api2/dashboard/users/send_user_details_export emails a per-guest export. Shortfalls that keep this below yes: every documented route is per-guest or event-driven - the Platform Functions Users group enumerates ban/unban, send_message, reactivate, deactivate, delete, patch, send_user_details_export, extensive_timeline, favourite locations, info and redemption, with no list or bulk-download operation, and the Mobile API index has no export group either; the export endpoint delivers by email rather than as a retrievable file; and gift-card liability balances have no documented operator-side export at all. https://developers.partech.com/docs/dev-portal-webhooks-manager/events/guest · retrieved 2026-08-09 adversarially verified
Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator
commercial-post-termination-export-window
Subscription Services Agreement (v2.0, 11.14.25) section 11.e, 'Return of Customer Data/Transaction Data': 'Provided Customer has paid all Fees and other amounts due under this Agreement, ParTech will extend Customer's access to the ParTech Services for a period of sixty (60) days beyond the expiration or early termination of this Agreement. During such period, Customer may extract any data in appropriately available formats for each ParTech Services... After such sixty (60) day period, ParTech shall have no obligation to maintain or provide any access to Customer Data and may thereafter, unless legally prohibited, delete all Customer Data.' Longer retention is available by agreement and continued payment of the applicable subscription Fees. Conditions worth recording: the window is contingent on the account being paid in full; hands-on help is chargeable ('Any assistance required by Customer to execute such data extraction will be provided by ParTech in a cooperative fashion as professional services, billed at prevailing rates and payable in advance'); self-service export in the Admin Portal covers customers, sales, labor, settings and surveys as CSV; and section 12.c states flatly that on termination 'ParTech will have no obligation to maintain, deliver or provide access to any Customer Data', so 11.e is the operative carve-out. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08
Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator
commercial-data-ownership-clause
Ownership is unambiguous. Subscription Services Agreement (v2.0, 11.14.25) section 11.c: 'Customer has and shall retain sole and exclusive title and ownership of all information and data, including all derivatives and transformations thereof, input by Customer or Authorized Users into the ParTech Services', covering card-derived data and payment Transaction Data. The constraint the claim also requires is where it fails. The same clause licenses ParTech to use Customer Data not only to perform the agreement but '(y) to offer or develop other ParTech products and services and/or alternative pricing structures' - unrestricted and not de-identified - while the de-identification limit attaches only to the third limb, '(z) to create derivatives of Customer Data, solely in de-identified and aggregated form', with ParTech owning that Aggregated Data outright and free to share it with affiliates and across the ParTech Services. Section 11.f additionally authorises disclosure of all of a franchisee's location data to its franchisor or authorised reseller, with a release of liability. The payment terms go further: PPS Terms section 4.1, 'Merchant acknowledges that PPS or Acquirer may retain and use Transaction data during and after the term of this Agreement without restriction and may share such data with third parties, including, but not limited to third party service providers', with PPS or Acquirer the sole owner of the aggregated data. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08
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
PAR POS is proprietary commercial SaaS from a public company. No source availability or self-hosting option. https://partech.com/solutions/cloud-pos/ · retrieved 2026-08-01
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
Half the claim is documented. Subscription Services Agreement 5.d: 'ParTech shall protect and secure the Customer Data and Transaction Data (both as defined herein) within the PAR Pay Services in accordance with the requirements of the PCI-DSS.' Tokenization is defined in the contract at 11.d - a 'Customer Token' is 'a derived alphanumeric value that is linked with a Gift/Debit/Credit card and is only used within Customer's database of Customer Data to uniquely identify a customer; it cannot be used to process a payment transaction' - with card data otherwise handled in masked (last four) and unmasked classes. Hardware entry is documented in the PAR Pay EMV Setup Guide on Ingenico and Verifone PIN pads ('A customer can dip, swipe, tap or manually enter their card'), and trust.partech.com carries a PCI SSF badge. Named shortfall: the other half is missing entirely - no validated P2PE solution or application listing is claimed on trust.partech.com, in the fifteen contract documents, or anywhere on cdn.parpos.com, and no SAQ type is named in any published PAR document, not SAQ A, not SAQ P2PE-HW, not SAQ C. Without a named SAQ the scope-reduction assertion this claim tests is simply never made. https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf · retrieved 2026-08-08
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
PAR documents one of the claim's two named controls, and only on one of the two named surfaces. Register logins: PAR POS 5.15r2 (Nov 2025) shipped "Secondary Authentication PIN for Register Sign-On (BRNK-55231)" - "PAR POS now supports a Secondary Authentication PIN as an additional layer of security when accessing registers. This new feature allows businesses to require a second user-entered PIN after the primary PIN login method, helping to prevent unauthorized access and supporting compliance with stricter security policies. Secondary Authentication PIN is configurable and can be enabled per employee." The release note's own use case is headed "Customer has enabled MFA for all team members", and the 5.16r2 Admin Portal Configuration Guide carries the field on the employee record: "Secondary Authentication PIN: Additional layer of security for employee register access. Must be a three to 12-digit numeric PIN." It is settable through the API as SecondaryAuthPIN on Settings2.svc/SaveEmployees. Shortfalls, all four material: (1) two sequential PINs are two knowledge factors, not two distinct factor types, so this does not satisfy PCI DSS Req 8.4.2/8.5 as written, and PAR nowhere cites v4.0.1 or Req 8.4.2, 6.4.3 or 11.6.1 in any published document; (2) back-office MFA is still unbuilt - the same guide's Admin Portal User configuration page reads "Enable Multi-Factor Authentication: Place Holder for future development (MFA)", so the claim's "back-office logins" half is not met; (3) nothing is published on payment-page script integrity monitoring for hosted ordering pages, and the trust center Security Overview 3.9 commits only to a secure development methodology, secure coding standards, automated secure code review, annual vulnerability scans and annual penetration tests; (4) PAR's published PCI posture is the Software Security Framework FAQ, whose offered artifact is "our most recent PA-DSS AOC for PAR POS as well as our Letter of Engagement from our third-party consultant" (Coalfire, 18 Oct 2022), with SSF certification described as still in assessment - a lifecycle standard, not a DSS v4.0.1 control statement. Checked the 5.16 and 5.16r2 release notes and Features QRGs, the PAR Pay 2024 PCI Upgrade notice and the full cdn.parpos.com document index for a newer MFA or script-integrity statement; there is none. https://cdn.parpos.com/release-notes/5.15r2ReleaseNotes.pdf · retrieved 2026-08-08 · not refetchable · site policy · graded B when read
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
Security Overview (v2.0, 11.14.25), incorporated into the Subscription Services Agreement by section 5.d, clause 3.3 'Audits of ParTech's Information Security Program': 'ParTech shall cause an independent third party to conduct at least once each year a SOC 1 Type II audit and a SOC 2 Type II Audit of the ParTech Services for ParTech's Services. ParTech will provide a copy of these reports upon Customer's request, subject to the Customer's confidentiality obligations under the Agreement.' That is both limbs of the claim - a current attestation held, and the report provided on request under confidentiality. Corroborated on trust.partech.com, which carries a SOC 2 badge, states 'PAR maintains a SOC 2 Type II report that outlines the design and operating effectiveness of our security and privacy controls', and indexes 'SOC 2 Type 2', 'SOC 2 Type 1' and 'SOC 1 Type 2' documents. Not established: the report period, the assessing firm, and whether coverage spans every ParTech Service or only the hosted platform - the trust center publishes no dates, and no ISO 27001 certification is claimed for ParTech itself (ISO 27001 appears only as an example of a report PAR may seek from its own subprocessors, Security Overview 3.10(iv)). https://partech.com/wp-content/uploads/2026/02/04-Security-Overview-v2.0-2025-11-14.pdf · retrieved 2026-08-08
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
Citation re-pointed and evidence replaced 2026-08-09; the old note's inference from webhook status names is withdrawn in favour of the endpoints themselves. Punchh documents the full data-subject-request path under the operator's business admin key: GET /api2/dashboard/users/info fetches a guest "by user ID, phone number, or email address"; POST /api2/dashboard/users/send_user_details_export "Emails a guest export to the guest as well as the requester"; DELETE /api2/dashboard/users takes reason delete_general ("Deletes the user and all associated transaction data permanently") or anonymize_forget_me ("Deletes all of the user's PII (personally identifiable information), while keeping anonymized transaction data for reporting integrity. This is in compliance with GDPR/CCPA standards"), after a required deactivation step and a configurable grace period defaulting to 7 days. Shortfalls that keep this at partial: the documented tooling is an API, not the in-app self-service DSAR console the claim describes - no Punchh platform admin-UI screen for locating, exporting or deleting a guest is documented publicly; and no executable Data Processing Addendum is published - partech.com/legal/ and partech.com/data-processing-addendum/ both 404, the partech.com privacy policy contains no DPA reference or link, and punchh.com/privacy-policy/ 404s. https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users/delete/api2/dashboard/users · retrieved 2026-08-09 adversarially verified
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
No accessibility conformance report is published, and PAR's own compliance registry enumerates what is. The PAR Technology Trust Center (SafeBase) lists the frameworks PAR claims under a 'Compliance' heading — CCPA, CIS Controls 8.1, EU-US DPF, GDPR, NIST CSF, PCI DSS, PCI SSF, PIPEDA, RH-ISAC and SOC 2 — and no accessibility standard is among them; the adjacent Documents index carries Cyber Insurance, a Responsible AI Statement and the security policy set, with no VPAT or ACR. Absence control: 'VPAT', 'WCAG 2.1', 'accessibility conformance', 'conformance report', 'ADA', 'Section 508' and 'screen reader' each occur ZERO times across all 1,358 documents; 'accessibility' occurs in 9, none of them a conformance assertion. This settles the published-artefact question the claim actually asks; it is not a finding about how accessible the kiosk is. Bounded to a corpus frozen 2026-09-09: partech.com's WordPress REST API across all seven public content types (799 documents; the type registry at wp-json/wp/v2/types and the Yoast sitemap index reconcile — the only sitemap entries absent from the REST census are taxonomy archives), the 531-page developers.partech.com sitemap (which equals its llms.txt exactly, so that pair is one table rendered twice and is a FLOOR, not a census), and the 28 OpenAPI documents the per-section llms.txt files name. https://trust.partech.com/ · retrieved 2026-09-09 automated extraction
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
The Admin Portal guide documents a "Non-Cash Adjustment" surcharge style: "Allows the restaurant to take the interchange fee which it has to give to the processors for a credit card payment from the guest. If the guest pays by cash, they do not have to pay the interchange fee. If the guest pays through credit card, the interchange fee is added to the bill amount," configurable as Fixed or Percentage Per Order/Item and itemized as a "Surcharges" line on the order. Shortfall: no documented automatic debit/prepaid-card exclusion and no documented receipt/menu-board disclosure requirement — the card-network compliance mechanics themselves are not spelled out. https://cdn.parpos.com/docs/PARPOS5.16r2AdminPortalConfigGuide.pdf · retrieved 2026-08-04 · not refetchable · site policy · graded B when read adversarially verified
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 103 values — 68 upheld, 28 downgraded, 7 upgraded. It separately resolved 164 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Pricing and identity
| Field | Verdict | What the verifier found |
|---|---|---|
| pricing.software | upheld | Verified and the rejection of the aggregator figure is correct. PAR's own Cloud POS FAQ says: "Pricing depends on your business size and needs. PAR offers flexible plans for single and multi-location restaurants. Contact PAR sales for a customized quote." No dollar figure anywhere on partech.com. Separate correction to the ICP prose, not a scored cell: that same FAQ explicitly markets "single and multi-location restaurants," which softens the dossier's flat assertion that single-unit operators are not the buyer. source |
| pricing.processing_rate | upheld | Verified. The payments page markets "highly competitive rates" and nothing else — no bps, no interchange-plus markup, no per-transaction figure. source |
| pricing.hardware | upheld | Verified. PAR Wave, PAR Volt, PAR Tablet, KDS, bump bar, headsets and the Drive-Thru Timer are all described with zero SKU pricing and no drop/IP ratings. source |
| identity.scale | upheld | Every figure checks out against the May 7 2026 release: revenue $124M up 19.4%, ARR $330.1M up 16% (11% organic, from $283.6M in Q1'25), Engagement Cloud $198.3M / Operator Cloud $131.8M, 199,300 total active sites, adjusted EBITDA $8.9M. One addition the dossier omits: Bridg contributed $14.4M of that ARR, so the inorganic share is explicit. Bridg close date also confirmed — Cardlytics announced completion March 24, 2026, receiving 1,810,222 PAR shares against a $27.5M purchase price (max $30.0M with adjustments). [Citation re-homed 2026-08-09: businesswire.com 403s every crawler, so the release was re-read in PAR's own Exhibit 99.1 to its 2026-05-07 8-K. Revenue $124.0M +19.4%, ARR $330.1M +16% (11% organic), Engagement Cloud $198.3M, Operator Cloud $131.8M, adjusted EBITDA $8.9M and Bridg's $14.4M ARR contribution all verify verbatim. One correction: '199,300 active sites' is not a figure the release prints — it is the sum of Engagement's 139.0 thousand and Operator's 60.3 thousand active sites as of March 31 2026. Correct, but derived rather than quoted.] source |
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| order-capture-offline-order-entry | partial (documented) | downgrade-to-unknown | Source misread — this is the dossier's most consequential error. The Brink FAQ setting is Settings Editor > Options > Online Ordering > General: "Accept Orders When Master Offline", and the FAQ states it lets API order submissions succeed when the Register is offline "though it won't receive them." That is a cloud-side setting governing whether the ordering API accepts inbound orders during a store outage — it is affirmative evidence the store does NOT receive orders while the master is down, and says nothing about terminal-side offline order entry. Confidence "documented" is not supportable; the only offline-mode assertions I could find are on reseller pages (bestpos.com), and partech.com's own Cloud POS page does not mention offline operation at all. source |
| hardware-offline-mode | partial (documented) | downgrade-to-unknown | Rests on the same misread setting. No PAR-published statement that terminals operate offline, and no degradation list. source |
| reliability-offline-order-entry | partial (documented) | downgrade-to-unknown | Same misread. The cited FAQ line does not "confirm offline order acceptance" at the POS; it confirms cloud-side acceptance of API orders the register will not receive. source |
| reliability-lan-degraded-multi-terminal | partial (inferred) | downgrade-to-unknown | Inference stacked on the misread: the existence of a 'Master' in a setting name is not documentation of degraded-LAN multi-terminal behavior. Nothing in the FAQ describes terminal-to-master behavior during a WAN outage. source |
| reliability-local-transaction-engine | partial (inferred) | downgrade-to-unknown | Same. Single-tenant vs multi-tenant server distinction in the rate-limit guidance is about PAR's cloud hosting tiers, not an in-store transaction engine. source |
| kitchen-order-ready-callback | yes (documented) | downgrade-to-unknown | Category error. DoorDash's mandatory "Order Ready Signal" is the integration telling DoorDash a delivery order is ready for courier pickup — it is not a kitchen-to-front-of-house / guest-facing ready callback. I confirmed the DPIP requirement list (SSIO, Menu pull, 86 items + Item Polling, Order Ready Signal, Integrated Promotions, Detailed Error Reporting) but none of it evidences an in-store KDS ready callback. The Brink Kitchen service exposing queue/bump times is read-only reporting. source |
| kitchen-channel-pause-propagation | partial (documented) | downgrade-to-unknown | DPIP proves self-serve store activation for DoorDash only. The sub-feature asks for a pause propagating to Uber Eats and Grubhub, which the researcher's own note concedes is undocumented — that concession should have produced 'unknown', not 'partial'. source |
| digital-qr-table | yes (claimed) | downgrade-to-unknown | I read the cited PAR Ordering page: it names "web, mobile, kiosks, catering, and third-party platforms" and conversion tools "preordering, upselling, secret menus, and cart-based incentives." QR table ordering is not named. The Digital Experience page does not name it either. The 'yes' is not supported by its own source. source |
| digital-group-ordering | yes (claimed) | downgrade-to-unknown | Group ordering appears on neither the PAR Ordering page nor the Digital Experience page. Scored 'yes' against a page that does not contain the claim. source |
| order-capture-catering | yes (claimed) | downgrade-to-partial | Catering appears only as a destination in the menu-sync channel list, and "PAR Catering" is a separate offering whose Learn More links off to punchh.com — i.e. a distinct product, not a documented capability of PAR Ordering. No catering order-management functionality is described. source |
| order-capture-scheduled-orders | yes (claimed) | downgrade-to-partial | The cited page's only supporting word is "preordering" in a list of conversion tools. That is thin for a 'yes' on scheduled orders, and fire-time injection is admittedly undocumented. source |
| order-capture-voice-ai | partial (claimed) | downgrade-to-unknown | Stale evidence. SYNQ3 Restaurant Solutions was acquired by SoundHound AI (announced Dec 2023, ~$25M, closed Jan 2024) and no longer exists as an independent partner. The cited press release predates that. No current PAR page or doc names a voice-AI partner or a first-party voice product. Scoring a live capability off a dead company's press release is exactly the failure mode to avoid. source |
| digital-voice-ai-phone | partial (claimed) | downgrade-to-unknown | Same stale SYNQ3 source; partner absorbed into SoundHound in Jan 2024 and the arrangement's current status is undocumented. source |
| digital-drivethru-ai | partial (claimed) | downgrade-to-unknown | Same. PAR's own hardware page documents G5 drive-thru headsets and a Drive-Thru Timer but says nothing about AI voice ordering. source |
| labor-payroll-export-formats | yes (claimed) | downgrade-to-partial | Wrong source: a 291-entry partner directory is not evidence of export formats. The correct evidence is the PAR OPS Workforce page, which lists "Payroll export" as a bare bullet with zero detail — no named format (Gusto/ADP/Paychex/QuickBooks), no field spec. Also note the PAR OPS overview page enumerates only Inventory, Labor, and Reporting & Analytics and names no payroll providers, so 'Netchex and 7shifts' is unsourced in the pages I checked. source |
| extensibility-payroll-export | yes (claimed) | downgrade-to-partial | Same defect — scored against the partner directory. A bare "Payroll export" bullet supports partial at best. source |
| inventory-invoice-ocr | yes (claimed) | downgrade-to-partial | Scan Assist ("Scan paper invoices for instant EDI receipts creation") is explicitly listed as a premium add-on, not part of any base PAR OPS module. Priority-1 attack: paid add-on, not native included capability. The researcher's own note said 'premium add-on' and scored yes anyway. source |
| guest-loyalty-ai-offer-recommendation | yes (claimed) | downgrade-to-partial | Sole source is the PAR Intelligence marketing page, and the researcher's own note says 'verify in a demo that it is GA, not roadmap.' A cell you cannot confirm is shipped cannot be a 'yes'. source |
| reporting-guest-cohorts | yes (claimed) | downgrade-to-partial | The Punchh page I read supports only "real-time dashboards track participation, ROI, and performance metrics" plus open APIs. New-vs-returning, frequency, and lifetime-spend cohort reporting is not documented; Bridg is an identity-resolution acquisition, not a documented cohort report. source |
| reporting-realtime-dashboard | yes (claimed) | downgrade-to-partial | The cited Cloud POS page's actual wording is "fully cloud-enabled, which means you can manage menus, pricing, and reporting remotely." Remote access to reporting is not a documented real-time dashboard, and the researcher concedes mobile access is unconfirmed. source |
| reporting-multiloc-drilldown | yes (claimed) | downgrade-to-partial | Marketing-page 'yes' where the note itself says drill-down to individual transaction is not documented. Drill-down is the sub-feature. source |
| hardware-handheld-battery-swap | yes (claimed) | downgrade-to-partial | PAR Tablet has no swappable battery; the 'yes' rests entirely on a marketing spec of "10-hour battery life" with no test standard or duty-cycle definition. (The swappable-module language on the hardware page belongs to PAR Volt compute modules, not batteries.) A vendor battery-life number is claim-level and should not clear a hot-swap bar. source |
| guest-loyalty-cdp-event-api | yes (documented) | downgrade-to-partial | The Webhooks Manager documents guest create/update/delete only. A CDP event feed needs transaction/order events, which PAR explicitly does not push — its own guidance is to poll GetOrders with a ModifiedTime filter. The researcher scored 'partial' for exactly this on extensibility-webhooks-push and reporting-webhooks, then 'yes' here; inconsistent. source |
| menu-pricing-fractional-placement | unknown (inferred) | resolve-to-no | Adverse upgrade in precision. Settings2 exhaustively enumerates the menu model — Menu, MenuCategory, MenuItem, ModifierGroups, ModifierGroupItem, ItemModifierGroup, ItemModifierCodePricing, ItemIncludedModifier, ItemCompositeComponent(-Item), ItemDestinationAvailability, PriceLevel, ItemPriceChange, ComponentPriceChange — and contains no placement, portion, section, or fraction field anywhere. This is the 'product docs clearly enumerate the alternative' case, so an affirmative 'no' is warranted rather than 'unknown'. source |
| menu-pricing-half-and-half-rule | unknown (inferred) | resolve-to-no | Same basis: with no placement dimension in the modifier model there is no object a half-and-half pricing rule (max/average/sum of halves) could attach to. Corroborated by Capterra reviewers describing the system as lacking pizzeria capability. source |
| menu-pricing-dayparting | unknown (inferred) | resolve-to-yes | Researcher missed a real object. Settings2 documents JobMenu: MenuId, Days (byte bitmask, 1-64, additive for multiple days) and StartTime (TimeSpan) — "Time at which the scheduled menu will begin displaying." That is time-and-day-scheduled menu switching. Caveat: it is scoped by employee job/role and I found no scheduled price change, so if the rubric requires daypart pricing as well as daypart menus, score partial rather than yes. source |
| menu-pricing-topping-quantity-tiers | unknown | resolve-to-yes | Also missed. Settings2 documents ItemModifierCodePricing (Id, ModifierCodeId, Price) with the note that "valid modifier codes are the ones that have charge type as 'Modifier Code Pricing'" — i.e. a modifier's price varies by its preparation code (the NO/LIGHT/EXTRA/SIDE family). That is a documented differential-price-by-quantity-code mechanism. Caveat: PAR does not publish the modifier-code enumeration itself, so if the rubric demands named light/regular/extra tiers, score partial. source |
| menu-pricing-included-allowance | unknown | resolve-to-yes | Missed object: ItemIncludedModifier (IsIncluded, AutomaticallyAdd, PrintInKitchen, Position) models modifiers bundled into an item at no charge and auto-applied. Caveat: it is a per-modifier included flag, not an 'N toppings included then charge for the N+1th' counted allowance, so partial is the defensible landing spot if the rubric requires a counted allowance. source |
| order-capture-order-ready-signal | yes (documented) | upheld | Verified. DoorDash's DPIP requirement list expressly includes "Order Ready Signal" as one of eight mandatory high-quality features, and PAR is named in the 2026 roster alongside Checkmate, Chowly, Deliverect, Otter, Qu, Square, Stream, Toast and UrbanPiper. Scope caveat: this evidences the DoorDash-channel signal only, not a guest-facing or in-store ready notification. source |
| delivery-86-sync | yes (documented) | upheld | Verified independently: "86 items" and "Item Polling" are both on DoorDash's mandatory capability list, with rolling 28-day enforcement (order failure rate and merchant cancel rate each below 1%, 250+ DoorDash stores to qualify as Established), and PAR holds 2026 PIP status. source |
| payments-processor-choice | yes (claimed) | upheld | Held to the highest bar and it survives. PAR's payment services page states verbatim: "Bring your own payment processor, hardware, and growth ambitions.", "Pick your processor. Your hands are never tied." and "Either use the PAR gateway, or don't. It's your choice." Still claim-level (no named list of supported processors, no contract text), but it is an explicit, unambiguous vendor commitment — genuinely differentiating versus Toast/Square/Clover. source |
| commercial-processing-not-bundled | yes (claimed) | upheld | Same verified quotes. Note the page simultaneously markets "highly competitive rates" with no figure, so processing is unbundled but unpriced. source |
| extensibility-oauth-partner-apps | no (documented) | upheld | Verified at the source. The developer portal states the header format `Authorization: Token token=LOCATION_KEY_GOES_HERE, btoken=BUSINESS_KEY_GOES_HERE` and "If you do not have these keys, reach out to your Punchh representative." Sandbox and production base URLs must also be requested from a rep. Brink side is the same pattern: the FAQ tells you to email api.support@partech.com or call (800) 403-9027 for tokens, and diagnoses failures with "Are you provisioned to access this location with your API account's AccessToken?" Static tokens, per-location provisioning, no OAuth, no operator-granted scopes. Minor sourcing nit: the cited URL documents the Punchh POS call, not the Brink auth scheme. source |
| extensibility-published-rate-limits | partial (documented) | upheld | Verified verbatim: "5 concurrent calls with a sleep of 2-3 minutes in between calls" (multi-tenant) vs "10 concurrent calls with a sleep of at least 1 minute" (single-tenant); save batches capped at 100 and delete batches at 20, "RPM should not be more than 5 requests per minute." Guidance, not enforced quota semantics — partial is correct. source |
| extensibility-menu-write-api | partial (documented) | upheld | Verified: SaveItems, SavePriceChanges and UpdateItemPrice are the only documented writes, and GetMenu retrieves structure with no modification capability. Asymmetry is real. source |
| reliability-public-status-page | partial (documented) | upheld | Verified live: exactly two components (PAR PAY WALLET API, 'Merchent Service Portal' — sic), 100.0% 90-day uptime, 14-day incident history, all operational as of 2026-08-01. Payments only; no POS/Ordering/Punchh status page exists. source |
| reliability-contractual-uptime-sla | unknown | upheld | Correctly unknown, but flag for the reader: PAR's Cloud POS page markets "99.99% uptime and handles 200M+ transactions monthly" and "on-time opening rates ... approach 99%". Those are marketing metrics with no contract, no credit schedule, and no measurement definition — do not let them drift into an SLA cell. source |
| labor-native-payroll | no (documented) | upheld | Supported by enumeration rather than by the quoted sentence: the PAR OPS page lists exactly three modules — Inventory Management, Labor Management, Reporting & Analytics — and mentions no payroll processing anywhere. PAR does not run payroll. source |
| labor-native-scheduling | yes (claimed) | upheld | Verified first-party: "PAR OPS™ Workforce" is PAR's own scheduling software, "currently helping 80+ leading brands", with a Suggested Scheduling Tool that "applies a sophisticated algorithm to predict restaurant demand" and an Employee Mobile App. Claim-level but self-consistent and clearly not resold. source |
| delivery-3p-reconciliation | yes, grade D, cites partech.com/solutions/insights-and-delivery-solutions/ | downgrade-to-partial | A differentiator yes cannot stand on a solutions page, so I went looking for product documentation and there is none. delaget.com/delaget-delivery/ now 302s to partech.com/delaget/, a placeholder - "Delaget is now part of PAR Technology" - offering a client login and parops.support@partech.com and nothing else. The only primary artifact PAR publishes for this product line is the Delaget Connect API (OpenAPI 3.0.4, api.delaget.com); I pulled the spec and searched it: no occurrence of delivery, DSP, DoorDash, Uber, Grubhub or reconcil- in any path or schema, and its nine paths are organizations, workers, retail_transactions, location summary, time_cards, shift_diff and two diagnostics. The solutions page itself only claims it "simplifies reconciliation and operations for all your delivery service providers" and "Connect instantly to DoorDash, Uber Eats, and Grubhub platforms" - it never says what is matched to what, and it splits the work across two modules (Delivery Operations, Recovery). The capability is plainly real; the yes is not evidenced. Partial, with the shortfall named: separate PAR OPS module, three DSPs only, no documented order-level or payout-level match. source |
| inventory-theoretical-vs-actual | yes, grade D, cites the PAR OPS Inventory marketing page | downgrade-to-partial | I found the PAR OPS back office's own OpenAPI specs, linked from the PAR OPS page on developers.partech.com (dc01.rmdatacentral.com/Portal1240/api/swagger/{portal,portalV2,shiftworks}/swagger.json), and searched all three. Variance tracking exists and is configured: store fields NegativeUsage, VarianceUsageThreshold and EnableInventoryEstimating, store-item fields VarianceUsageTargetQty and NegativeUsageQtyLimit, plus counts (with Estimate and RefreshFromTemplate), waste templates, invoices and purchase orders. But "theoretical" and "ideal" do not occur anywhere in any of the three specs, there is no recipe or item-build endpoint that would let POS sales be exploded into theoretical usage, and no variance report is exposed. The researcher's own note conceded the report granularity was undocumented and scored yes anyway. Partial: the actual side and the variance thresholds are documented; the theoretical calculation is asserted only in marketing copy. source |
| reporting-sales-forecast | yes, grade D, cites the PAR OPS forecasting marketing page | upheld | Value stands and the evidence moves D->A. The PAR OPS Portal v2 OpenAPI documents GET /v2/Forecast/{forecastId}/{date} returning seven days across Sales, Entree, Checks and Guests; SevenDaysSales and SevenDaysEntrees category filters; POST /v2/Forecast/Regenerate/{forecastId}/{date}, which "will cancel all applied revises"; PATCH /v2/Forecast/ByMinutes and /MultiUnit/ByMinutes setting revised amounts "for the specific forecast and time"; SevenDaysLock/SevenDaysUnLock at unit and multi-unit scope; GET /v2/Forecast/SevenDaysWeather/{date}; GET /v2/Forecast/Formats; and /v2/EventForecast plus /v2/StoreEventForecast with targets and a sales chart. The researcher wrote "daypart/hourly granularity not confirmed" - it is now confirmed: ByMinutes is per-time and the schedule forecast charts return hourly buckets. source |
| labor-demand-labor-forecast | yes, grade D, cites the PAR OPS forecasting marketing page | upheld | Value stands and the evidence moves D->A. Same spec: GET /v2/StoreSchedule/ScheduleForecast "Returns a list of Schedule Projections and daily requirements", parameterised by ScheduleTemplateID and period; GET /v2/StoreSchedule/ProjectedSales returns projected sales per business date; GET /v2/StoreScheduleForecastCharts/ProjectedData and /ActualData return a week at Interval 01:00:00 from StartTime 06:00:00, i.e. hourly projected against actual. Schedule templates and scheduleBases are exposed at store, multiStore and administrator scope. This is a demand forecast feeding a labour requirement, documented rather than claimed. Deliberately not asserted: whether the requirement is broken out by job or duty as the marketing page's "team forecasting by shift and job duties" implies - the ScheduleForecastModel is not expanded in the spec text I could read. source |
| guest-loyalty-wallet-pass | yes, grade D, cites the PAR Digital Experience marketing page and its Smart Passes copy | upheld | I found real documentation and the value survives, at grade B. PAR's POS developer docs carry an Apple Wallet pass integration guide: "Apple Loyalty Passes, part of Apple Wallet, contain various details like loyalty points, the user's name, email address, etc.", with a One-Tap Flow over NFC on certified terminals and an Alternative Flow in which "the POS system should have a Punchh integration and a scanner to scan the user's QR code or barcode for user/redeemable look-up", resolving through the Punchh User Look-up API. The Punchh API FAQ separately references a Punchh Wallet integration blueprint. One correction to the record's note: Google Wallet is not mentioned anywhere in the integration document, so the note should not present Apple and Google as equally attested. source |
| guest-loyalty-targeted-offers | yes, grade D, cites partech.com/solutions/par-intelligence | upheld | The cited PAR Intelligence page is exactly the "generates and deploys targeted campaigns" copy this pass exists to reject, so I looked for the mechanism and found it. The Platform Functions API reference lists Custom Segments as a first-class endpoint group, and the Custom Segment guide documents nine operations: list, create, update and delete a custom segment, and add, remove, search, bulk-add and bulk-remove guests within one. The Campaigns page defines a campaign as "a scheduled batch job or triggered action that adds gifts... for users, typically targeted at a particular user segment", and Offers is a documented Mobile API domain. Segment-targeted scheduled offer delivery is documented. Limit worth recording: the segment endpoints manage membership, not criteria, so predicate-based rule authoring is not evidenced by these docs. source |
| digital-native-app | yes, grade D, cites the PAR Digital Experience marketing page | upheld | Upheld at grade B on the Punchh Mobile API reference, which states the APIs deliver loyalty "primarily via business-branded mobile apps and websites tailored by Punchh" - PAR documentation asserting it produces the branded app itself, which is what the claim is about; a mobile API alone would not have sufficed. The documented domains are a complete consumer-app surface: Accounts and User management with social login, Offers, Coupons, Collectibles, Challenges, Check-ins, Badges and Beacons, Drive-Thru, Gift Cards, Locations, Notifications, Payment Cards and Payments, Redemptions 2.0, Referrals and loyalty transfers, Surveys, Single Scan Codes, WiFi acquisition. Not established: whether PAR ships native iOS/Android SDKs - the getting-started page mentions none, so the app is likely delivered as a Punchh-built product rather than an SDK the brand embeds. source |
| menu-pricing-modifier-price-by-parent-size | unknown (placeholder — cell never examined) | resolve-to-no | Settings2's exhaustively enumerated menu model — the same enumeration this record's adversarial pass accepted as positive absence for fractional placement — offers only ModifierGroupItem.Price/PriceMethod and ItemModifierCodePricing for modifier pricing; PriceLevel is item-scoped and no size dimension exists anywhere. A per-parent-size price matrix has no object to live on; the achievable configuration is duplicated modifier groups, which the claim expressly excludes. source |
| payments-refund-void-controls | unknown (placeholder — cell never examined) | resolve-to-partial | Settings2 SecurityLevel documents discrete VoidItems/ApproveDiscounts/DeletePayments permissions and Sales2 attributes actor and approver on voids and discounts (OrderItemVoid.ApproverEmployeeId, OrderDiscount.EmployeeId+ApproverEmployeeId), queryable via GetOrders. Refunds are only Order.IsRefund+RefundReasonId with no approver, and no no-sale control or immutability statement is documented — hence partial, not yes. source |
| delivery-zone-pricing | unknown (placeholder — cell never examined) | resolve-to-partial | DestinationDeliveryZone (Name, Coordinates, SurchargeId) plus LimitByDeliveryZone/ValidDeliveryZones document polygon zones with per-zone fees via surcharge; per-zone order minimum and promise time have no documented fields. source |
| digital-account-saved-payment | unknown (placeholder — cell never examined) | resolve-to-partial | Punchh Mobile API documents Accounts, Payment Cards and Payments endpoint groups for business-branded apps, and the getting-started guide links /api2/mobile/secure_tokens/{service} — guest accounts with tokenized payments are evidenced; saved addresses and one-tap reorder are not documented, so the claim cannot clear partial. source |
| guest-loyalty-consent-management | unknown (placeholder — cell never examined) | resolve-to-partial | The eClub Guest Upload endpoint documents marketing_email_subscription gated by an Explicit-Opt-in business flag, an SMS compliance/opt-in flow (send_compliance_sms), terms/privacy booleans and a validated source parameter. Consent timestamps and any-reasonable-means revocation across channels are not documented. source |
| guest-loyalty-redemption-fraud-controls | unknown (placeholder — cell never examined) | resolve-to-partial | Settings2 SecurityLevel enumerates OverrideDailyLoyaltyCardLimit and ApproveLoyaltyCards — a documented daily loyalty-card velocity limit with role-gated override. Manual-adjustment approval, self-redemption flagging and a loyalty audit log remain undocumented. source |
| labor-granular-rbac | unknown (placeholder — cell never examined) | resolve-to-partial | SecurityLevel objects carry 26+ discrete per-action permission booleans and Jobs bind DefaultSecurityLevelId — genuinely per-action, not fixed tiers, and location-scoped. Held to partial because two of the claim's enumerated actions (report access, price change) have no documented permission and portal-side RBAC is not public. source |
| labor-manager-override-audit | unknown (placeholder — cell never examined) | resolve-to-partial | Sales2 carries ApproverEmployeeId on OrderItemVoid, OrderDiscount, OrderPromotion and OrderSurcharge alongside the applying EmployeeId, queryable via GetOrders — individual approver attribution, after-the-fact. No immutability statement and no approver on refund orders keep it at partial. source |
| labor-tip-distribution-audit-trail | unknown (placeholder — cell never examined) | resolve-to-partial | PAR OPS Payroll OpenAPI documents TipShareHours, TipShareAmounts (CalculatedAmount/PostingAmount per StoreEmployee/Job), TipShareContribution, TipShareJobWeights, TipShareSettings and TipShareAmountToPayroll; portalV2 CashBalancing adds per-employee per-business-date TipShareOutAmount; jobs carry TipShareMethodEnum {None, Contributor, Recipient}. Partial because this is the separately sold PAR OPS back office, not the POS, and no per-employee tips-received record is in the public spec. source |
| reporting-pmix-modifier-level | unknown (placeholder — cell never examined) | resolve-to-partial | Sales2 documents modifier-level order detail (OrderItemModifier with Price) plus per-line DayPartId and RevenueCenterId, and PAR OPS has a PmixTracking account category — the data substrate is complete, but no modifier-level PMIX report UI is publicly documented, so the report claim itself lands partial. source |
| reliability-printer-fallback | unknown (placeholder — cell never examined) | resolve-to-partial | Printer.BackupPrinterId and PrinterGroup.RoutingOverrides are documented configuration; the automatic unreachable-printer detection and staff alerting the claim requires are not described publicly. source |
| kitchen-expo-consolidation | unknown (placeholder — cell never examined) | resolve-to-yes | 5.16r2 Admin Portal Config Guide documents 'Is Expediter' kitchen queues that display check marks beside order items as they are bumped from each non-expo kitchen queue, Bump From Other Kitchen Queues, an Order Expediter Action on expo bump, and expo-sequence controls (Prioritize Expeditor Only Items, out-of-sequence identification on expo). Multi-station consolidation with per-station bump tracking is the documented mechanism. source |
| kitchen-printer-fallback | unknown (placeholder — cell never examined) | resolve-to-partial | Edit Printer dialog has a designated 'Backup Printer' drop-down and 5.16 added printer reroutes that follow KDS queue reroutes and persist — but nothing public states failover is automatic on printer failure or that tickets are preserved; documented reroutes are operator-initiated. Consistent with the earlier settings2 finding on reliability-printer-fallback. source |
| labor-break-compliance-by-state | unknown (placeholder — cell never examined) | resolve-to-partial | PAR OPS portalV2 OpenAPI has a jurisdiction-scoped (country/state/county/city) Autocompliance engine with MealPeriodPenalty rules (MinBreakMinutes, PenaltyMinutesAwarded, PenaltyRate, ScheduleValidation), penalty lines with BreakRequiredAfter/TakeBreakWithin and SignedWaiver, RestPeriodBetweenShiftsRule and TimeclockThresholdRule. Premium pay for missed breaks is explicit; an employee-facing attestation prompt is not documented, keeping it at partial. source |
| labor-minor-labor-rules | unknown (placeholder — cell never examined) | resolve-to-partial | portalV2 OpenAPI documents /v2/Autocompliance/MinorRule (MinAge/MaxAge, SchoolInSession, Weekdays, jurisdiction scoping, effective dates), per-employee school calendars, and /v2/StoreSchedule/MinorRules/Validate plus /Override for scheduling enforcement. Clock-in-time enforcement is not documented — POS-side clock-in enforcement is generic schedule punctuality only — so partial. source |
| inventory-unit-conversion-yields | unknown (placeholder — cell never examined) | resolve-to-yes | ItemUM in the PAR OPS portalV2 OpenAPI stores per-item units flagged Purchase/Recipe/CountYN/Waste with ConversionFactor and YieldPercent per unit, and recipe-content models expose per-ingredient ConversionFactor and Yield used in costing — the claim's exact structure, in primary API documentation. source |
| reporting-tip-tax-compliance | unknown (placeholder — cell never examined) | resolve-to-partial | Employee Timecard Report documents per-employee per-shift Non-Cash Tips vs Declared Tips with sign-off lines; Must Declare Tips prompts at clock-out with a system-calculated minimum; Declared Tips and per-location tax reports exist. No tip-pool distribution detail report is in the documented Admin Portal report list and no jurisdictional rollup beyond per-location tax summaries, so partial. source |
| reliability-offline-kds-printing | unknown (placeholder — cell never examined) | resolve-to-yes | In-Store Resilience release notes: on complete internet loss 'offline mode operates normally with the primary register acting as the host'; kitchen terminals are named members of the local terminal topology and kitchen printers attach to registers, so kitchen routing is locally hosted. Held at yes on the documented local-hosting architecture despite no device-by-device offline narration. source |
| reliability-sync-conflict-handling | unknown (placeholder — cell never examined) | resolve-to-partial | The resilience doc documents partition-time guardrails (15-minute block on clock-out/checkout/drawer assignment on the Backup Primary), automatic self-correction and resynchronization on reconnect, and acknowledges multi-register same-order edit conflicts with an added prevention layer — but never states the resolution rule (LWW/merge/prompt) for conflicts that do occur. source |
| commercial-hardware-purchase-outright | unknown (placeholder — cell never examined) | resolve-to-partial | PAR manufactures and sells its own hardware (hardware product revenue is a reported earnings line), so outright purchase is the model and no mandatory lease is published; but the hardware page publishes no prices and no acquisition terms at all — the claim's published-price prong fails, landing partial. source |
| order-capture-seat-level | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The 5.16r2 Admin Portal Config Guide documents seat-level order capture end to end: the Table Service job option "Group Items by Seat: Order items displayed on the Order List control are grouped by Seat Number. Pressing the 'Next Person' button on the register advances to the nex source |
| order-capture-split-merge | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents "Split Order": "Opens 'Split Order' screen, which allows for adding new orders to the current party, moving items between the orders, splitting individual items, and combining (un-splitting) split items," gated behind a "Split Check" security-leve source |
| order-capture-transfer-audit | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents a "Transfer Items"/"Transfer Party" register behavior: "Opens the Transfer Party window that allows the current employee to select tables or tabs to transfer to another employee." Shortfall: no dedicated audit report or log entry naming both the t source |
| order-capture-void-comp-controls | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents the full chain: a Void Reasons list ("Refund reasons are listed for the employee to choose when the 'Refund' button behavior is executed"; five default reasons include 86'd Item, Kitchen Error, Server Error, Test Order, Waste); role-gated Security source |
| menu-pricing-versioning-effective-dates | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. Changeset Publisher stages a named package of changesets and schedules its activation as "Immediately" or "End of Day" (the target location's own End of Day time) up to two weeks in the future, running an automatic pre-validation check before Submit. Shortfall: no visual preview source |
| menu-pricing-dynamic-pricing | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-no | Resolved during the 2026-08-04 placeholder-rationale sweep: scored no at grade B. Settings2's menu/pricing object model — already accepted elsewhere in this record as an exhaustive enumeration (PriceLevel, SavePriceChanges/UpdateItemPrice, ItemPriceChange, ComponentPriceChange) — contains no time-of-day, demand, or channel-variable pricing rule and no floor/ce source |
| payments-tip-adjust | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents "Allow Tip Adjust On Register: When tender Type is set to Credit Card or Gift Card and [enabled, staff can adjust] the register via 'Adjust Tips' or 'Adjust Payment' buttons," a CanAdjustTipsFromAnyTill security permission (a manager-level cross-t source |
| payments-tip-pooling | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents "Tip Pooling Enabled: Allows for the definition and management of employee tip pools," with per-job "Contribute to Tip Pool" (percentage of compensation) and "Receive Distributions from Tip Pool" flags. The PAR OPS Payroll API (already cited in th source |
| payments-split-tender | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide's Split Order screen supports moving/splitting items across multiple new orders from one party, and the Pay at Table section states a check "can be paid in full or split among multiple guests at the same table." Shortfall: no explicit tender-count cap or co source |
| payments-card-on-file | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents "Enable Stored Credit Cards: Credit cards can be stored on customer accounts" for the in-store channel. On the digital side, the Punchh Mobile API (already cited in this record) documents Payment Cards/Payments endpoint groups and a secure_tokens source |
| kitchen-sla-alerts | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents a per-kitchen-queue "Thresholds tab": "Color: Color of the order card border," "Seconds: Number of seconds after the order appears in the queue to apply the threshold style," "Flash: Flash the order card timer," and "Mode: Animate/Switch" — config source |
| kitchen-offline-operation | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The In-Store Resilience release notes (already cited elsewhere in this record for reliability-offline-kds-printing) state that on complete internet loss "offline mode operates normally with the primary register acting as the host" — all in-store terminals, including kitchen displ source |
| kitchen-recall-refire | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents "Recalled Border: Color of the border surrounding orders that have been recalled" on the Kitchen View (unbump), plus "Reprint Previous Items Sent: Reprints items that were previously sent to the kitchen on chits for orders that items were later ad source |
| kitchen-order-modification-alerts | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide's Kitchen View format options document "Edited Items: Color of order items that have been edited after being sent to the kitchen" and "Editing Items: Color of order items that are in the process of being edited after being sent to the kitchen," plus a separ source |
| delivery-zones-polygon | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. Settings2 documents DestinationDeliveryZone with a "Coordinates" field (alongside Name and SurchargeId) — a polygon/coordinate-defined delivery area, not solely a radius or ZIP/postcode list. source |
| delivery-address-validation | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. Settings2 documents Destination fields "LimitByDeliveryZone: True if delivery address is to be limited to specific zones" and "ValidDeliveryZones," gating orders to configured delivery-zone polygons. Shortfall: no documented geocoding provider or address-level validation/rejectio source |
| labor-offline-time-punch | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The In-Store Resilience release notes document a 15-minute guardrail that explicitly blocks "Clocking Out" (alongside Checking Out and Cash Drawer Assignment) on the Backup Primary register immediately after it takes over from a failed primary, "to decrease the frequency of state source |
| labor-realtime-labor-percent | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents an Admin Portal dashboard "Summary" widget showing "Net Sales, Labor cost, Sales Per Labor Hour, the number of employees Clocked In" together, and a "Sales & Labor" widget graphing net sales and labor cost by hour when viewing a single day. Shortf source |
| labor-overtime-prevention | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents an "Overtime" alert: "Send alert when an employee goes from regular time to overtime." Shortfall: this fires as an email alert at or after the moment of crossing into overtime, not as a clock-in warning or block before the overtime is incurred, wh source |
| labor-fair-workweek-support | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade A. The PAR OPS (Data Central) portalV2 OpenAPI documents a jurisdiction-scoped predictive-scheduling rules engine: /v2/Autocompliance/ScheduleRule (AutocomplianceScheduleRuleGetDto) carries CountryID/CountryStateID/CountyID/CityID, EffectiveStartDate/EndDate, Threshold, PenaltyType, source |
| labor-tip-pooling-rules | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents "Tip Pooling Enabled: Allows for the definition and management of employee tip pools," with per-job "Contribute to Tip Pool" (percentage of compensation) and "Receive Distributions from Tip Pool" flags. The PAR OPS Payroll API (already cited elsew source |
| labor-server-performance-metrics | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide's "Employee Sales Summary" report lists "key performance metrics for each employee," its "Item Sales By Employee"/eligible-sales reports track item-group attach rate by employee, and "Void Details" is "grouped by employee." Shortfall: no single report is do source |
| inventory-par-auto-suggest | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade A. The PAR OPS (Data Central) portalV2 OpenAPI's PurchaseOrderPostModel documents a per-line SuggestedOrderQuantity together with PredictionCalculationID and a PredictedUsages array of per-date forecasted usage (e.g. {"PredictionDate":"2022-12-01","Usage":2.0}) — a forecast-driven s source |
| inventory-waste-logging | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade A. The PAR OPS portalV2 OpenAPI documents "Waste and Store Waste Templates" as a distinct object family from the usage-variance apparatus (NegativeUsage, VarianceUsageThreshold — already cited elsewhere in this record), i.e. a structured waste-logging mechanism kept separately repor source |
| inventory-commissary | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade A. The PAR OPS portalV2 OpenAPI's Vendor model carries ProductionKitchenID/ProductionKitchenDescription/ProductionKitchenNumber fields and a UsePOCostForCommissary flag — a location can be configured as an internal supply "vendor" with a designated production kitchen and a purchase- source |
| inventory-cogs-gl-export | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade A. The PAR OPS portalV2 OpenAPI documents dedicated named-format export endpoints: POST /v2/QuickBooks/ExportAccountingData ("Exports Accounting Data into QuickBooks according to GL export format") and POST /v2/QuickBooks/ExportPurchases ("Exports purchase documents into QuickBooks" source |
| reporting-comps-voids-audit | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents "Void Details" (grouped by employee, sorted by void time), "Void Summary" (totals by void reason), and "Manager Override Detail" ("Lists details regarding all manager override actions, including: Approval Time, Login User, Button Name, Button Acti source |
| reporting-server-scorecards | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. Same evidence as labor-server-performance-metrics: Employee Sales Summary, Item Sales By Employee/eligible-sales-%, and Void Details (grouped by employee) are documented, but no single per-server report combines average check, items-per-check, and tip percentage as one scorecard. source |
| reporting-custom-report-builder | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-no | Resolved during the 2026-08-04 placeholder-rationale sweep: scored no at grade B. The Administrator Portal's Reports section enumerates a fixed catalog of roughly sixty named canned reports across Sales, Employees, Inventory, Comparative and Audits categories (Product Mix, Sales Summary, Void Details, Employee Productivity, etc.), each with a fixed description source |
| reporting-scheduled-delivery | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents "Scheduled Reports": "reports that are automatically generated and sent via email at a particular time or system event," configurable by Schedule Type (End of Day/Specific Time), Days of Week, Report Locations, a list of attached Reports, and a "R source |
| multi-location-scheduled-publish | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. Changeset Publisher schedules a changeset package to publish "Immediately" or at "End of Day" — the target location's own End of Day time, itself a per-location setting — up to two weeks in advance, with a pre-validation check before submission. Shortfall: no rollback-to-prior-st source |
| multi-location-corp-vs-franchisee-roles | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents an "Ownership Types" attribute on locations — "All Ownership Types, Corporate, or Franchisee" — filterable in the Admin Portal. Shortfall: no documented permission boundary distinguishing what a corporate user can see/enforce versus what stays und source |
| multi-location-royalty-calculation | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents royalty entries defined as a percent of net sales or a flat dollar amount per month, with Start/End Date effective ranges and a "Limit Location" scope, feeding the "Royalties by Location" report. Shortfall: only a net-sales basis is documented — n source |
| multi-location-royalty-collection | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide's Options > Accounting > Royalties tab carries Bank Account Number and Routing Number fields stated to appear "on the Royalties by Location report." Shortfall: no automated ACH/debit collection execution flow is documented — these are display/reporting fiel source |
| multi-location-cross-location-giftcard | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents Gift Card Filters that "restrict the locations at which gift cards can be redeemed or applied," via a "Filter Locations: Limit gift card tendering by location" list — implying cross-location redemption is configurable when the filter spans multipl source |
| multi-location-multi-brand | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents Item "Brand Allocation": "Distribute sales of the item across more than one brand" by weighted percentage, with Product Mix reporting grouped by brand. Shortfall: this is a sales-attribution mechanism for accounting purposes, not documented suppor source |
| multi-location-config-audit-log | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. Changeset Publisher/Changeset Packages record "Created By" (full name of the publishing user), "Created Time," per-changeset entity-level change detail (viewable by clicking the change count), and an exportable CSV of publish status per location — a queryable, corporate-visible r source |
| multi-location-central-labor-policy | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. Overtime rules (Day Hours/Week Hours/Shift Hours/Day-In-Week, with a per-rule pay-rate Factor) are configured per location via Settings Editor, and the PAR OPS Autocompliance ScheduleRule/MealPeriodPenalty/MinorRule engines (already cited elsewhere in this record) are jurisdictio source |
| extensibility-custom-fields-scripting | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-yes | Resolved during the 2026-08-04 placeholder-rationale sweep: scored yes at grade B. The Admin Portal guide documents "Custom Fields" (Admin Portal > Configuration > Custom Fields): an operator adds a new field via "+ New Field," then applies it to Items/Promotions with no vendor engineering engagement. Separately, "Script Functions are VB Script functions that c source |
| reliability-mfa-role-based-access | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. Role-based permissions are extensively documented (SecurityLevel's 26+ discrete booleans, already cited elsewhere in this record). MFA, however, is explicitly documented as not yet functional: "Enable Multi-Factor Authentication: Place Holder for future development (MFA)." source |
| reliability-self-serve-training | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents a Training Mode at the register/kitchen level: "Indicate Training Mode on Kitchen Chits: Automatically prints 'Training Order' and 'Do Not Make' on kitchen chits while training to prevent waste." Shortfall: no public, free video/LMS training libra source |
| reliability-failover-terminal-role | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The In-Store Resilience release notes document automatic failover to a pre-elected "Backup Primary" register: on primary-register network loss, the backup "swiftly assumes control and continues operating in offline mode" without manual intervention. The backup is auto-elected amo source |
| commercial-privacy-dsar-tooling | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The developer portal's Webhooks Manager guest-event documentation (already cited elsewhere in this record) references deleted, anonymized, and archived guest states, implying deletion/anonymization workflows exist server-side, and Punchh's eClub consent primitives (already cited source |
| commercial-dual-pricing-compliant | unknown (no public documentation located during the 2026-08-01 research pass) | resolve-to-partial | Resolved during the 2026-08-04 placeholder-rationale sweep: scored partial at grade B. The Admin Portal guide documents a "Non-Cash Adjustment" surcharge style: "Allows the restaurant to take the interchange fee which it has to give to the processors for a credit card payment from the guest. If the guest pays by cash, they do not have to pay the interchange fee. If source |
| order-capture-drive-thru-timers | yes, grade B - PAR sells a first-party Drive-Thru Timer product for monitor | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| order-capture-scheduled-orders | partial, grade B - The cited page's only supporting word is "preordering" in a | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| order-capture-catering | partial, grade B - Catering appears only as a destination in the menu-sync chan | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| kitchen-bump-bar-hardware | yes, grade B - PAR sells a programmable bump bar alongside its KDS. | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| delivery-3p-direct-integration | partial, grade B - DoorDash direct integration is certified (2026 DPIP). PAR OP | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| guest-loyalty-ai-offer-recommendation | partial, grade B - Sole source is the PAR Intelligence marketing page, and the | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| labor-native-payroll | no, grade B - Supported by enumeration rather than by the quoted sentence: | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| labor-payroll-export-formats | partial, grade B - Wrong source: a 291-entry partner directory is not evidence | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| inventory-invoice-ocr | partial, grade B - Scan Assist ("Scan paper invoices for instant EDI receipts c | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-realtime-dashboard | partial, grade B - The cited Cloud POS page's actual wording is "fully cloud-en | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-multiloc-drilldown | partial, grade B - Marketing-page 'yes' where the note itself says drill-down t | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| reporting-guest-cohorts | partial, grade B - The Punchh page I read supports only "real-time dashboards t | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-handheld-battery-swap | partial, grade B - PAR Tablet has no swappable battery; the 'yes' rests entirel | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-kds | yes, grade B - First-party KDS sold with a programmable bump bar and dockin | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| hardware-pricing-transparency | no, grade B - No SKU-level prices anywhere on the hardware page; the page | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| extensibility-first-party-delivery-integrations | partial, grade B - DoorDash direct and certified. Uber Eats and Grubhub connect | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| extensibility-payroll-export | partial, grade B - Same defect — scored against the partner directory. A bare " | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-pricing-published | no, grade B - partech.com has no pricing page and no dollar figures for so | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| commercial-source-available-selfhost | no, grade B - PAR POS is proprietary commercial SaaS from a public company | upheld | Grade only, value untouched. Corpus-wide mechanical pass (workflows/regrade-marketing-pages.mjs): the cited page is a first-party pricing/feature/product page, which atlas-evidence-rules grades C ("vendor pricing page or feature page - first-party, but written to sell"), not B ("vendor product documentation - the manual, the help centre, the admin guide"). No claim was re-researched in this pass and no evidence was re-read; only the grade was brought into line with the source type. source |
| payments-processor-choice | yes / B / "Held to the highest bar and it survives. PAR's payment services page states verbatim: \"Bring your ow" | upheld | The cited evidence was partech.com/solutions/payment-services/, a first-party sales page (grade C at best) whose quotes are marketing commitments, not a documented processor list. Located PAR's real documentation host, cdn.parpos.com/Documentation.html, and retrieved the DataCap EMV USA Payment Matrix and the EMV Card Processor Configuration Guide. The matrix names eleven supported processors and the configuration guide gives seven PAR-certified gateway/processor/device combinations, so the claim survives on documentation rather than on the sales page. source |
| commercial-processing-not-bundled | yes / B / "Same verified quotes. Note the page simultaneously markets \"highly competitive rates\" with no f" | upheld | Original evidence was the partech.com payment-services sales page, which is a marketing commitment and cannot carry a differentiator yes. Retrieved PAR's EMV Card Processor Configuration Guide and the 5.16r2 Admin Portal User Guide from cdn.parpos.com: the former enumerates six non-PAR certified gateways and their processors, the latter documents the Credit Processor / Processor Type configuration screen driven by credentials the merchant's own processor supplies. Capability confirmed on documentation; the guide also shows a set of features available only on PAR Pay, which is recorded in the note. source |
| labor-native-scheduling | yes / B / "Verified first-party: \"PAR OPS(TM) Workforce\" is PAR's own scheduling software, \"currently helping 8" | upheld | The original evidence was the PAR OPS Workforce product page - marketing copy naming a product, which cannot carry a differentiator yes. Retrieved the 306-page PAR POS 5.16r2 Admin Portal User Guide from PAR's documentation index and found the capability documented at the mechanism level in the Brink admin portal itself, not merely in the separate PAR OPS back office: Labor > Scheduler builds and saves shift schedules, Labor > Edit Shifts holds the timekeeping actuals, and the Weekly Labor Schedule report plus the Shift Exceeds Scheduled alert compare the two. Stronger than the claim as originally evidenced. source |
| inventory-native-not-partner | yes / B / "PAR OPS Inventory is PAR's own first-party product, not a resold or separately-contracted third pa" | upheld | The original evidence, partech.com/products/par-ops/, is a first-party product page that names the product without describing anything, so it could not carry a differentiator yes. Located PAR OPS's own web-service reference on the Restaurant Magic host and confirmed the capability at operation level - recipe cards and recipe ingredients under DC_Item, count costing and recipe re-calculation under DC_Inventory, purchase orders and vendor invoices under DC_Purchasing - all PAR-operated. Also checked the Brink 5.16r2 Admin Portal guide, which contains no inventory functionality at all, so the module is separately licensed from the POS; that is recorded in the note but does not make it third-party, which is what the claim tests. source |
| order-capture-floor-plan-editor | unknown | resolve-to-partial | Table and Section objects with capacity and party-by-table lookup are documented; a graphical editor with shapes, multiple saved layouts and section-to-server assignment is not. source |
| order-capture-coursing-hold-fire | unknown | resolve-to-no | The complete published order/order-item schema has no course field and the only manual kitchen-release operation is whole-order SendOrder. source |
| order-capture-bar-tab-preauth | unknown | resolve-to-partial | Pre-auth with a configurable amount is documented in the PAR Pay device settings and API; incremental re-auth and stale-tab auto-close are not. source |
| order-capture-offline-order-entry | unknown | resolve-to-yes | First-party release notes document registers continuing to operate in offline mode and publish the list of functions that are unavailable while offline. source |
| order-capture-qr-same-check | unknown | resolve-to-no | The complete Ordering.svc operation set and NewOrder schema provide no way to add items to an existing open check; PAR's QR guest product is pay-at-table, not order-to-check. source |
| order-capture-throttling | unknown | resolve-to-partial | Per-destination lead/prep-time thresholds are documented; per-slot capacity limits and automatic load-driven quote extension are absent from the complete FutureOrderingOptions schema. source |
| menu-pricing-size-style-matrix | unknown | resolve-to-no | The complete item and price-level schemas expose only scalar prices and per-modifier-code prices; no two-axis price grid construct exists. source |
| menu-pricing-countdown-auto-86 | unknown | resolve-to-partial | Per-item available quantity with zero-means-86 is documented in the ordering API; decrement-on-sale semantics and a scheduled auto-restore are not. source |
| menu-pricing-dual-pricing | unknown | resolve-to-partial | A non-cash adjustment exists as a PAR Pay tender-time setting; item-level dual pricing with card-price-as-base across POS, kiosk and online ordering is absent from the item and menu-item schemas. source |
| menu-pricing-allergen-nutrition | unknown | resolve-to-no | The complete item schema and the online-ordering menu-item schema both lack any allergen or nutrition field, and the ingredient link carries no quantity. source |
| payments-dual-pricing | unknown | resolve-to-partial | A non-cash adjustment is documented on the PAR Pay device integration, but no second price per item and no both-totals check or receipt printing. source |
| payments-surcharge-guardrails | unknown | resolve-to-no | The complete published Surcharge configuration type has no card-type/BIN/product-code dimension and no network cap; the only card-aware surcharge is an unconditional non-cash adjustment. source |
| payments-softpos-tap-to-pay | unknown | resolve-to-no | The complete supported payment-device list is eight physical-terminal integrations and the PAR Pay API has no phone-reader path. source |
| payments-offline-store-and-forward | unknown | resolve-to-yes | First-party configuration documentation names store-and-forward plus a per-transaction amount cap and a cumulative offline-transaction count cap with defaults. source |
| payments-multi-entity-routing | unknown | resolve-to-partial | Per-location merchant/terminal IDs are documented across the payment-device integrations with unified Admin Portal reporting; PAR-side control of settlement bank accounts or split settlement is not. source |
| payments-p2pe-pci4 | unknown | resolve-to-partial | PAR publishes a QSA engagement letter and undertakes to supply its AoC on request, but the AoC on offer is PA-DSS (retired 2022) with no current PCI DSS 4.x attestation or P2PE listing. source |
| kitchen-course-firing | unknown | resolve-to-no | The complete kitchen service and KDS configuration schemas contain no course concept, and the only manual fire action is whole-order. source |
| kitchen-prep-time-pacing | unknown | resolve-to-no | The complete item configuration schema has no cook-time field, so per-item cook times cannot be configured and there is nothing for a KDS to stagger against. source |
| kitchen-order-throttling | unknown | resolve-to-no | Both the Admin Portal kitchen configuration screens and the API kitchen types are enumerated and contain no load-triggered release delay or quote extension. source |
| kitchen-channel-pause-propagation | unknown | resolve-to-partial | A documented per-destination item-availability API lets connected marketplaces pick up 86s, but there is no store-pause object, no push mechanism and no Uber Eats/Grubhub documentation. source |
| kitchen-item-build-screens | unknown | resolve-to-partial | Modifier breakout on kitchen video groups is documented; recipe-step and portioning build detail has no field in the schema to come from. source |
| kitchen-pizza-fractional-display | unknown | resolve-to-no | The complete modifier and order-item-modifier schemas have no half/quarter/section placement field, so no fractional placement can reach a make-line display. source |
| kitchen-guest-ready-notification | unknown | resolve-to-yes | First-party configuration guide documents a guest-facing order-status board driven automatically by the KDS queue bump. source |
| kitchen-waste-logging | unknown | resolve-to-partial | Waste exists as a configurable void reason captured at the register; KDS-screen logging and inventory depletion are absent from Brink itself. source |
| delivery-driver-roster | unknown | resolve-to-partial | Read the 8,425-line text of the 5.16r2 Admin Portal Config Guide plus the Settings2 Job type table. Driver and dispatcher are configured job roles with an assignment screen and a dedicated security permission, but no run-state machine and no per-driver run-history report exist in the enumerated report catalogue. source |
| delivery-dispatch-board | unknown | resolve-to-partial | The Admin Portal guide's register button-behavior table - the complete configurable register surface - documents the Assign Delivery Order screen, its order filter and its driver filter, but no elapsed-time display and no run batching. source |
| delivery-driver-comp | unknown | resolve-to-partial | Checked the Admin Portal guide for driver payment ownership and tip declaration, then enumerated every schema in the Delaget Connect API (the PAR OPS Insights & Delivery API linked from developers.partech.com/operations-tools/par-ops/). Tips and a separate reimbursement line exist; mileage and per-delivery reimbursement do not. source |
| delivery-cash-reconcile | unknown | resolve-to-partial | Read the Admin Portal guide's till, checkout, clock-out and report sections. A declared-cash checkout with a printed checkout report and a Till History report covers self-banking employees generally; no driver-specific settle-up or over/short report is documented. source |
| delivery-daas-dispatch | unknown | resolve-to-no | Enumerated the Order type field list and the full Ordering operation list on brinkapiportal.parpos.com, plus the register button-behavior table in the Admin Portal guide. An API schema with no courier/quote/status field, combined with a complete operation list containing no dispatch call, is positive evidence of absence for a native POS handoff. source |
| delivery-daas-fallback | unknown | resolve-to-no | Same enumeration as delivery-daas-dispatch, plus the Destination delivery-zone settings (LimitByDeliveryZone, ValidDeliveryZones, per-zone SurchargeId), which are address validation and pricing and carry no escalation rule. source |
| delivery-promise-time | unknown | resolve-to-no | The Prep Times and Lead Times tabs are a settings screen whose rule-type list is the entire configurable surface, and it enumerates four order-content rule types with no load, driver or drive-time input; the delivery leg is documented as an average constant per destination and modelled that way in the Settings2 API. source |
| digital-qr-table | unknown | resolve-to-partial | Read Options > Online Ordering (General, Destinations, Mobile In Store Destinations, Modifier Codes, Alternate Menus, In Store Alternate Menus), the Receipt Footer section and the Punchh external-processor section of the Admin Portal guide, plus the Settings2 PayAtTableOptions type. Mobile in-store ordering and a receipt QR exist; attach-to-open-check and guest split do not. source |
| digital-guest-data-ownership | unknown | resolve-to-partial | Read the Admin Portal guide's entire Export section (Customers, Sales, Labor, Settings, Surveys). A self-serve filtered customer CSV is documented; an ownership statement and a per-guest order-history export are not. source |
| digital-checkout-pci-sca | unknown | resolve-to-partial | Retrieved the rendered PAR Pay API reference and enumerated its 26 operations: a hosted iframe endpoint is present, 3DS and any PCI DSS 4.0 attestation are absent. Cross-checked the Brink Ordering payment union, which includes NewExternallyTokenizedCreditCardPayment. source |
| digital-surcharge-transparency | unknown | resolve-to-partial | Read the Surcharges entity section of the Admin Portal guide end to end - its tab list is the entire configurable surface of a surcharge - plus Options > Online Ordering > Destinations for the channel link, and the Settings2/Ordering surcharge types. Dual pricing and digital scoping are present; disclosure, card-brand and jurisdiction handling are absent. source |
| guest-loyalty-offer-stacking-rules | unknown | resolve-to-yes | Read the full Promotions type field list on brinkapiportal.parpos.com/settings2 from a complete dump of the portal. Four named combinability booleans, a Priority sort field and per-order caps are configuration rather than inference, and the Admin Portal guide links external loyalty rewards into the same discount engine via External ID. source |
| guest-loyalty-data-export-portability | unknown | resolve-to-partial | Read the Admin Portal guide's Export section in full and its loyalty retirement notes. A self-serve customer CSV exists; per-guest transaction history and any loyalty-ledger export do not, and the loyalty data itself is held by a separately purchased provider. source |
| guest-loyalty-review-capture-routing | unknown | resolve-to-partial | Read the Admin Portal guide's Receipt Footer, receipt/chit token, Marketing report and Export Surveys sections, and its Settings Editor survey entities. Trigger and reporting are documented; score-based routing is not, and PAR's native survey builder is retired. source |
| labor-photo-punch-verification | unknown | resolve-to-no | Three independent complete enumerations in the same first-party guide - the per-job login permissions, the per-employee login methods, and the Set Login behavior's parameter list - all give the same closed set of Card, Finger Scan and PIN, and the terminal peripheral list contains no camera. source |
| labor-geofenced-mobile-punch | unknown | resolve-to-no | Downloaded and enumerated all three PAR OPS OpenAPI specs (portal 239 paths, portalV2 813 paths, shiftworks 127 paths). The ClockIn operation's full parameter list contains no location field and no geofence object appears in any schema; the Brink register clock-in is terminal-bound. source |
| labor-qualified-tips-w2-reporting | unknown | resolve-to-partial | Enumerated every schema in the Delaget Connect API and searched all three PAR OPS OpenAPI specs for occupation, Box 12/14 and TP fields. Charged-versus-total tips and separate reimbursement lines are present; the Treasury occupation code and W-2 box mapping are absent from every schema. source |
| labor-digital-onboarding-i9 | unknown | resolve-to-partial | Downloaded all three PAR OPS OpenAPI specs and enumerated their schemas. The prior rationale searched portalV2 only and missed HRManagement.EmployeeI9Model, which lives in the v1 portal spec and hangs off EmployeeGetModel; E-Verify is genuinely absent from all three. source |
| inventory-86-auto-sync | unknown / grade F - PAR OPS portalV2 OpenAPI searched for sold-out/86 fields; only employee-scheduling Availability fields found | resolve-to-partial | The earlier pass searched the wrong product. Brink's own availability model is in the Admin Portal Settings Editor (Item Availability screen, per-order-channel columns) and in Ordering.svc (GetItemAvailability, UpdateItemAvailability, GetUnavailableItems with a DestinationId filter and a QuantityAvailable countdown). It is per-channel and API-readable, so third-party menus can consume it; but the configured threshold raises an email alert rather than auto-86ing, and no ingredient-level trigger exists. source |
| inventory-mobile-count-offline | unknown / grade F - PAR OPS portalV2 OpenAPI documents Counts/PeriodData but no mobile offline-capture-and-sync and no barcode/QR counting app | resolve-to-partial | The portalV2 REST swagger is not the whole PAR OPS surface. The older DC_Inventory SOAP service on rmhs.rmdatacentral.com enumerates an explicit handheld counting workflow - PDAGetCountBarcodes, PDAPrepareData, PDAReceiveData and their Zip variants - which is barcode-based counting with a download/upload sync cycle. It falls short of the claim because it is a separate product, is device-legacy rather than a documented tablet app, has no QR, and offline tolerance is never stated in words. source |
| inventory-menu-margin-linkage | unknown / grade F - no margin endpoint in PAR OPS portalV2 OpenAPI; recipe costing exists but no margin-threshold report joining it to sales mix | resolve-to-partial | The earlier pass looked only at the PAR OPS API and never opened the Brink Admin Portal report catalogue, which is enumerated report-by-report in the 5.16r2 configuration guide. Ideal Food Cost By Item is exactly the cost-versus-actual-sales join the claim asks for, runnable across locations and date ranges. The threshold-flagging half of the claim is genuinely missing: the guide's complete Alert Type list contains no cost or margin alert. source |
| reporting-raw-warehouse-export | unknown / grade F - searched PAR OPS swagger and partech.com for S3/SFTP/Snowflake/BigQuery export; only manual CSV found in the Admin Portal guide | resolve-to-no | The earlier pass had the right observation but treated it as failure to find. Re-read in full, the guide's Export section states its own scope in one closed sentence covering five tools, all of which produce a file for download, and the only scheduled delivery in the product emails PDF reports. The Brink API confirms it from the other side by prescribing per-business-date polling as the supported route to continuous data. That is an enumerated surface, not an absent search result. source |
| multi-location-normalized-item-rollup | unknown / grade F - searched the Admin Portal guide and PAR OPS portalV2 OpenAPI for a corporate/master item-ID rollup mechanism; none found | resolve-to-partial | The report catalogue in the same guide does document item-level sales rolling up across selected locations and across two groups of locations (Product Mix and Comparative > Product Mix), which is the substance of the claim, so unknown understated it. It falls short of yes because the documented key is item name, PAR ships a Menu Comparison report to detect cross-location divergence, and Brink IDs are explicitly per-location. source |
| multi-location-multi-currency-locale | unknown / grade F - searched the Admin Portal guide and PAR OPS portalV2 OpenAPI for a currency field; none found anywhere | resolve-to-no | Two independent enumerated surfaces agree, which is what lifts this above failure-to-find. Settings.svc's LocationOptions is the complete location settings object and lists Country and TimeZone with no currency sibling; no money type anywhere in 659 API operations carries a currency qualifier; and the complete Admin Portal/Settings Editor guide has no currency field either, its only locale feature being a French UI toggle. A reporting currency cannot be applied to amounts that are never denominated. source |
| multi-location-enterprise-sso | unknown / grade F - searched the Admin Portal guide for SSO/SAML/OIDC; none found. Documented login methods are magnetic card, finger scan and 4-digit PIN plus a placeholder MFA checkbox | resolve-to-no | The earlier pass conflated register sign-on with back-office accounts and stopped at a keyword search. Read properly, the Admin Portal User configuration page is the complete account-creation surface for the above-store users this claim is about, and it enumerates username, password, forced password change, password-by-email, a placeholder MFA checkbox, Limit Locations and Limit Roles - local credentials only, with no federation field to fill in and no automated deprovisioning path beyond setting a user Disabled. source |
| hardware-offline-mode | unknown / grade F - "Rests on the same misread setting. No PAR-published statement that terminals operate offline, and no degradation list." | resolve-to-yes | The premise was wrong: PAR does publish such a statement, in the In-Store Resilience / Backup Primary release notes linked from its own documentation index. That document says registers continue to function in offline mode both when the internet is lost and when the primary register fails, gives four situational examples and a step-by-step test procedure, and enumerates what stops - online ordering, changeset publishing, End of Day, cloud history sync - plus the conditions under which offline mode itself is not functional. Scored yes at grade B for a table-stakes claim; the one gap is that payment, loyalty and refund behaviour offline is not described. source |
| hardware-printer-compatibility | unknown / grade F - "PAR sells its own printers; multi-manufacturer ESC/POS and LAN printer support is not documented publicly." | resolve-to-yes | It is documented publicly, in the Settings Editor section of PAR's own 5.16r2 Admin Portal Configuration Guide. The printer Model drop-down is enumerated verbatim and spans Epson, NCR, PAR, Partner, Star and Zebra models, and the Epson TM-T88 family is configurable over Ethernet by TCP/IP address, which answers both halves of the claim - more than one manufacturer, and LAN printers. The Settings2.svc Printer type independently exposes Model, Interface (Ethernet/Serial/Windows) and the serial parameters. source |
| hardware-p2pe-terminal | unknown / grade F - re-checked partech.com/solutions/pos-hardware/; no PCI-listed PTS device, validated P2PE claim or merchant SAQ type stated on the page | resolve-to-partial | The marketing page was the wrong place to look. PAR's documentation index leads to a Software Security Framework FAQ and a PAR Pay RMA guide that together establish the first half of the claim - card entry happens on named dedicated Ingenico PIN pads under vendor-controlled firmware, not on the POS tablet - and simultaneously establish that the second half is absent: PAR's own attestation is PA-DSS with an SSF/P2PE assessment merely engaged in 2022, no PTS listing is cited, and no merchant SAQ type is stated. source |
| hardware-ownership-vs-lease | unknown / grade F - no purchase-vs-lease statement on partech.com; hardware revenue is a distinct earnings line but the vendor never explicitly states ownership vs lease terms | resolve-to-yes | The earlier pass used an earnings release, which shows only that a hardware line exists. The 10-K's accounting policy is the vendor's explicit statement of the transaction type: hardware is a product sale recognised at a point in time when the customer obtains control of the asset on delivery, with returns accepted, warranty reserved at sale, and it is contrasted in the same section with SaaS fees recognised ratably. That is a regulatory-filing statement that hardware is bought outright rather than leased or rented as part of the subscription. source |
| hardware-rma-sla | unknown / grade F - checked partech.com/solutions/pos-hardware/ and /solutions/cloud-pos/; neither publishes a warranty term or a replacement/advance-exchange turnaround SLA | resolve-to-partial | Both marketing pages were the wrong source. PAR's own documentation index links a PAR Pay RMA Quick Reference Guide that publishes exactly the missing figures - Standard 3-4 business days at a $200 fee with no contract, Advanced Exchange 2-3 business days with no fee under contract, 10 business days to return or be billed full price plus 15% - and the 10-K confirms an overnight Advanced Exchange programme and extended warranty repair service. It stops short of yes because the SLA is scoped to payment devices and PAR publishes no warranty term for customers. source |
| hardware-remote-device-management | unknown / grade F - checked partech.com/solutions/pos-hardware/ and /solutions/cloud-pos/; neither documents a remote console showing terminal/printer/KDS online status, remote reboot or staged update rollout | resolve-to-partial | The console is documented in the Admin Portal guide, not on the marketing site. The Devices page shows connection status for all Registers and Kitchen Displays with a Maintenance Service status column and Terminal Topology (IP address, machine ID), and Run End of Day is a remote action; the API adds GetMasterTerminalStatus. It stays short of yes because printers are absent from the view, no remote reboot or per-device software version is documented, and there is no staged rollout of software updates. source |
| hardware-callerid-integration | unknown / grade F - no caller ID hardware or telephony-integration product documented anywhere on partech.com | resolve-to-partial | partech.com was the wrong surface; the capability is in the Settings Editor. Options > System > Caller ID is a full configuration tab for a serial caller-ID device (Register, Model, Interface, COM Port, Reverse Caller Name) which "communicates caller name and number to the POS when an incoming call is received" and displays them at the top of the Future Order screen. It falls short of the claim's customer-record-and-history pop, which PAR nowhere describes. source |
| extensibility-bi-data-warehouse | unknown / grade F - same finding as reporting-raw-warehouse-export; no scheduled S3/SFTP/Snowflake/BigQuery export endpoint found, only manual CSV downloads | resolve-to-no | Re-read rather than re-searched. The configuration guide states the Export section's scope in one sentence enumerating five tools, all of which are downloads, and the product's only scheduled delivery mechanism attaches PDF reports to email. The Brink API independently prescribes per-business-date polling as the supported route to continuous transaction data. That is an enumerated surface with the capability absent from it, not an unsuccessful search. source |
| extensibility-data-portability-exit | unknown / grade F - consistent with api_posture.data_export_on_exit; no published post-termination data retrieval window or data-ownership clause found | resolve-to-partial | The exit-terms half is correctly unresolved, but the on-demand half is documented and was not looked at. The Admin Portal Export section gives the operator self-service downloads of customers, items, labor and GL-mapped sales in stated formats. It is partial rather than yes because orders and payments metadata are absent from that set - available only by day-by-day API polling under PAR-provisioned tokens - and no contract-end availability is committed anywhere. source |
| reliability-offline-order-entry | unknown | resolve-to-yes | The prior pass was right that the 'Accept Orders When Master Offline' FAQ setting is cloud-side and proves nothing about the terminal. The answer is in a document that pass did have but read only for payment content: the In-Store Resilience release notes' Testing and Validation section and FAQ both state registers keep operating in offline mode with the internet down. source |
| reliability-offline-card-auth | unknown | resolve-to-yes | The prior pass searched the In-Store Resilience notes and the PAR Pay EMV Setup Guide, both of which are genuinely silent on offline tender. SAF is documented in the contract layer instead: partech.com/terms-and-conditions/ publishes the Subscription Services Agreement, whose section 6.a is entirely about Store and Forward for PAR Pay. source |
| reliability-offline-decline-liability | unknown | resolve-to-partial | Found via the published Subscription Services Agreement rather than the product documentation. Section 6.a both disclaims all ParTech liability for SAF outcomes and makes the number/value cap a customer-set parameter with no published figures - one half of the claim answered, one half genuinely absent. source |
| reliability-lan-degraded-multi-terminal | unknown | resolve-to-yes | The prior pass was right to reject the 'Master' setting-name inference. Real evidence exists in the In-Store Resilience release notes: the four situational examples and the LAN-outage FAQ describe secondaries hosting off a local primary or backup-primary register over the store LAN while above-store services are down. source |
| reliability-local-transaction-engine | unknown | resolve-to-yes | The prior pass's rejection of the single-tenant/multi-tenant rate-limit inference was correct. The real evidence is a first-party architecture FAQ the record had not found (cdn.parpos.com/docs/5.0nArchitectureEvolutionFAQ.pdf, reachable from the cdn.parpos.com/Documentation.html index), reinforced by the Orbit in-store API in the Network Connectivity requirements. source |
| reliability-contractual-uptime-sla | unknown | resolve-to-yes | The prior pass's warning against the marketing 99.99% figure was right, but a real contract exists: partech.com/terms-and-conditions/ publishes the full PAR contract suite, including a PAR POS Service Level Commitment with 99.8% in-store and 98.8% above-store percentages and a four-tier service-credit schedule. source |
| reliability-incident-postmortems | unknown | resolve-to-partial | The prior pass checked status.parpay.partech.com only. There is a second, older and much larger status page for the POS product itself - status.parpos.com, named in the published Service Level Commitment. Read its incident feed end to end: causes are stated inline in resolution updates, but no RCA document is ever published, and the one incident that promised an RCA never delivered it. source |
| reliability-247-live-support | unknown | resolve-to-partial | Resolved from PAR's published Technical Support Services Terms rather than the phone numbers on the marketing site. 24/7/365 direct-to-restaurant phone support is contractual; the shortfalls are that support is a separately-feed item under SSA 5.a and 13.a and that the peer-to-peer route narrows to business hours with an after-hours pager for Priority 1 only. source |
| reliability-menu-build-service | unknown | resolve-to-partial | The prior pass looked only at partech.com/solutions/cloud-pos/. The Menu Maintenance Service Terms published at partech.com/terms-and-conditions/ reference a 'menu build statement of work' four times as an established ParTech professional service, which answers the question affirmatively but as a paid SOW rather than bundled onboarding. source |
| reliability-hardware-replacement-sla | unknown | resolve-to-yes | The prior pass concluded no warranty term or replacement SLA was published on partech.com. Both are published - the Terms of Hardware Sale on partech.com/terms-and-conditions/ carry a one-year depot warranty and purchasable one- or three-year Advance Exchange with next-business-day shipment, and cdn.parpos.com/docs/PARPayRMAQRG.pdf gives the payment-device RMA turnarounds. source |
| reliability-backup-restore | unknown | resolve-to-partial | The prior pass read the In-Store Resilience notes only for resynchronization behaviour; they also document a configurable 30-day local register.sdf backup retention. Then checked the published Security Overview for RPO/RTO, which substitutes 'a commercially reasonable period of time' for any figure - making the absence of RPO/RTO a positive contractual finding rather than a gap in the search. source |
| reliability-pci-dss-4-attestation | unknown | resolve-to-partial | The prior pass reported no trust center at all. One exists at trust.partech.com, linked only from the terms-of-use footer, and it names a 'PCI DSS v4.0.1' document in its index - enough to move off unknown - but the artifact is gated and the public statement carries no scope, date or SAQ. source |
| reliability-cellular-backup | unknown | resolve-to-partial | The prior pass checked partech.com and the In-Store Resilience notes. The answer is in a document neither pass had - cdn.parpos.com/docs/POSSystemRequirements.pdf, reachable from the cdn.parpos.com/Documentation.html index - which explicitly rates 3G/4G/LTE as viable for backup only. Also re-read PARPOSNetworkConnectivity.pdf in full looking for a failover mechanism; there is none. source |
| commercial-month-to-month-contract | unknown | resolve-to-no | The prior pass reported no publicly accessible MSA, terms of service or pricing page. partech.com/terms-and-conditions/ publishes the full contract suite, and both the Subscription Services Agreement (12.a) and the PAR Payment Services sub-merchant terms (8.1) set a three-year Initial Term as the standing default. This is a positive contractual finding on the vendor's own standard offer, not an absence of evidence. source |
| commercial-no-early-termination-fee | unknown | resolve-to-no | Read both published agreements in full. Far from stating no ETF, PPS section 8.2 imposes one computed as remaining-term fees and expressly calls it a reasonable estimate of damages, and the Subscription Services Agreement removes convenience termination entirely. Positive evidence against the claim rather than a failure to find terms. source |
| commercial-autorenew-terms-published | unknown | resolve-to-yes | The prior pass found no publicly accessible MSA. partech.com/terms-and-conditions/ publishes fifteen contract documents including the Subscription Services Agreement, whose section 12.a states the one-year auto-renewal and the 30-day notice window in the open. source |
| commercial-rate-increase-clause | unknown | resolve-to-yes | Resolved from the published PPS sub-merchant terms at partech.com/doc/04-sub-merchant-agreement_stand-alone/. Section 3.1 expressly disapplies the Early Termination Fee where the merchant closes the account over a fee change, which satisfies the claim's penalty-free-exit limb even though no rate cap exists. source |
| commercial-post-termination-export-window | unknown | resolve-to-yes | The prior pass and this record's api_posture.data_export_on_exit finding both concluded nothing was published. Subscription Services Agreement 11.e, published at partech.com/terms-and-conditions/, states a 60-day post-termination extraction window explicitly, with retention extendable by agreement. source |
| commercial-data-ownership-clause | unknown | resolve-to-partial | Resolved from the published Subscription Services Agreement (11.c and 11.f) and PPS Terms (4.1). Ownership is stated in the merchant's favour, so the claim is not simply unmet; but the vendor-use constraint it also requires is absent, and the payment terms explicitly permit post-termination retention, use and third-party sharing of transaction data without restriction. source |
| commercial-pci-p2pe-tokenization | unknown | resolve-to-partial | Checked the trust center's full item index, the fifteen contract documents at partech.com/terms-and-conditions/, and the PAR Pay guides on cdn.parpos.com. Tokenization is contractually defined and hardware EMV entry is documented, which takes this off unknown, but no P2PE validation and no SAQ type appear in any of them. source |
| commercial-pci-dss-4-controls | unknown | resolve-to-no | This is not an absence-of-evidence finding. The vendor's own current admin guide affirmatively documents merchant-facing MFA as a placeholder for future development, so the control the claim names as the marquee v4.0.1 future-dated requirement is documented as not implemented; the trust center's MFA statement is scoped to PAR employees only, and the Security Overview's application-security clause contains no script-integrity provision. source |
| commercial-soc2-attestation | unknown | resolve-to-yes | The prior pass reported no trust center or public SOC 2 statement on partech.com. Both exist: trust.partech.com, linked from the terms-of-use footer, and more strongly the Security Overview at partech.com/terms-and-conditions/, whose clause 3.3 commits contractually to an annual SOC 1 Type II and SOC 2 Type II and to providing the reports on request under NDA-equivalent confidentiality. source |
| order-capture-coursing-hold-fire | no / grade A - Two independent enumerations of the order model contain no course concept. | upgrade-to-partial | Re-read the register behavior table in the 5.16r2 Admin Portal Config Guide rather than the API type list. Three behaviors do the work the claim describes: Hold (Clusivity inclusive/exclusive of the selected items; Release Type Manual, Prompt for hold minutes, or Specific predefined minutes), Release ("Releases selected items that are currently being held so that they can be manually sent to the kitchen") and Send Order Items (sends only the selected unsent items that are not being held). The KDS has a dedicated Held Items colour. The enumeration argument was sound about the word "course" and wrong about the capability: an operator holds and fires a subset of the check by selection or timer, with no course object and no fire-next-course action. source |
| kitchen-course-firing | no / grade A - No course model exists to fire. Kitchen.svc enumerates exactly two operations | upgrade-to-partial | The Kitchen.svc enumeration is real but answers the wrong question: firing is a register behavior in Brink, not a kitchen-service call. The Admin Portal guide's behavior table documents Hold with three release types, Release ("...so that they can be manually sent to the kitchen") and Send Order Items for the selected unsent items, and the Kitchen View Format tab gives held items their own colour on the KDS. Hold-then-fire on demand from a terminal is therefore documented; the course entity and an expo-side fire control are what is missing. source |
| kitchen-pizza-fractional-display | no / grade A - No sectioned-topping model exists. The complete modifier surface in the published sch | upgrade-to-partial | The note asserted that "half", "quarter", "fraction" and "portion" occur zero times; that holds for the API dump but not for the first-party guide, where PAR's own example of a modifier code is HALF and the Kitchen General tab says modifier codes are consolidated "on both kitchen displays and printed kitchen chits". The Modifier Codes page gives each code an Abbreviation that prefixes or suffixes the modifier name and an optional dedicated KDS font colour. Fractional intent therefore does render on the make line, textually. What remains true is that no placement dimension exists on the order item, so left/right, quarters and specific sections cannot be expressed and nothing is drawn graphically - that is a shortfall, not an absence. source |
| order-capture-qr-same-check | no / grade A - The published order-injection surface cannot write onto an open check. Ordering.sv | downgrade-to-unknown | Re-read the cited Ordering.svc operation list and NewOrder type and confirmed both are as described. The enumeration does not meet the bar for this claim: it is the third-party integration API, and the claim is about the vendor's own guest QR ordering, which PAR ships (PARk it) and documents nowhere public. The predecessor named this as the no it would downgrade first, and the reason it gave is the right one - a first-party product can use a private path into Brink that the integration surface does not show. source |
| commercial-pci-dss-4-controls | no / grade B - "The claim's headline control is MFA for all access to the cardholder data envir" | upgrade-to-partial | The no read the Admin Portal user record's MFA placeholder as meaning PAR has shipped no additional authentication anywhere, but that line governs back-office accounts only. Walking the release notes on cdn.parpos.com turned up 5.15r2 (Nov 2025), which ships a Secondary Authentication PIN for register sign-on framed by PAR as "supporting compliance with stricter security policies" and whose own worked example is captioned "Customer has enabled MFA for all team members"; the field is also in the 5.16r2 guide the no cites, about 500 lines above the placeholder sentence, and in the API as SecondaryAuthPIN. I also read the Software Security Framework FAQ and the PAR Pay 2024 PCI Upgrade notice: the former still offers a PA-DSS AOC and a 2022 Coalfire engagement letter, the latter is a terminal firmware rollout. So PAR documents a POS-login hardening control and does not document back-office MFA, PCI DSS v4.0.1, or script integrity monitoring - partial with the shortfall named, rather than a flat absence. source |
| reliability-mfa-role-based-access | partial / grade B - "Role-based permissions are extensively documented (SecurityLevel's 26+ discrete boo" | upheld | Re-read the guide rather than the placeholder line alone. Partial stands, but the stated reason was wrong by omission: page 17's Register Access section documents "Secondary Authentication PIN: Additional layer of security for employee register access. Must be a three to 12-digit numeric PIN", corroborated by the SecondaryAuthPin field on the settings service's Employee type. The "Place Holder for future development (MFA)" checkbox is on the Admin Portal User page and governs back-office accounts only, so the shortfall is back-office MFA, not MFA outright. source |
| menu-pricing-fractional-placement | no / grade B - "Adverse upgrade in precision. Settings2 exhaustively enumerates the menu model - Menu" | upgrade-to-partial | The 'no' rested on settings2 being the exhaustive menu model; it is not the only configuration surface, and the 5.16r2 Admin Portal Configuration Guide contradicts the conclusion. Its kitchen options list HALF as a modifier code alongside ADD and NO in "Consolidate Like Modifier Codes", and its Modifier Code Pricing page assigns each modifier an independent price per code (API: ItemModifierCodePricing {ModifierCodeId, Price}), so half toppings are orderable and separately priceable. I upgraded rather than upheld a 'yes' because the Edit Modifier Code dialog and the API's ModCodeType enum offer only Normal / No / Sub / For / On Side - no placement, no quarters, and no field recording which half a modifier applies to. source |
| menu-pricing-half-and-half-rule | no / grade B - "Same basis: with no placement dimension in the modifier model there is no object a hal" | upheld | The recorded reasoning had to be withdrawn - it inherited the refuted 'settings2 is the exhaustive menu model' premise, and its Capterra corroboration is a source class barred from evidencing capability - so I re-derived the cell from the pricing surface itself. The Admin Portal guide's Modifier Codes, Modifier Code Pricing and Modifier Tiers pages, and the API's ModCodeChargeType enum (Undefined, Always, ChargeForNonIngredients, Never, UseModifierTiers, ModifierCodePricing), together enumerate every way a modifier can be priced: a flat per-code amount or a substitution tier comparison. No multiplier, no max-of-halves, no average-of-halves. At most one of the three behaviours the claim lists is configurable, so 'no' stands on evidence of enumeration rather than on the placement argument. source |
| digital-native-app | yes, grade B - "Upheld on independent evidence at grade B. The Punchh Mobile API reference states the API" | upheld | Stale-citation check. The cited slug .../bf6eddb435209-mobile-api 301s to .../apis/mobile-api; I retrieved the destination under a Googlebot UA (200, 96222 bytes; a fabricated sibling path returns a distinct 13758-byte Scalar 404, so a soft 404 is excluded) and the quoted sentence is present verbatim: loyalty is executed "primarily via business-branded mobile apps and websites tailored by Punchh". The endpoint-group list is intact. Value unchanged; citation re-pointed. source |
| digital-account-saved-payment | partial, grade B - "The Punchh Mobile API - PAR's documented surface for business-branded guest apps and web" | upheld | Stale-citation check. The cited slug 301s to .../apis/mobile-api (200 under a Googlebot UA). Rather than rest on the getting-started secure_tokens link, I opened the Payment Cards tag page itself, which the old note said was not publicly readable: it is, and it enumerates Fetch All Saved Payment Cards, Create a Payment Card, Update a Saved Payment Card and Delete a Saved Payment Card, so the saved-tokenized-payment half is now directly documented. I then read the full endpoint-group index and the Users tag page: there is no addresses group and no order-history or reorder endpoint, so the saved-addresses and one-tap-reorder halves remain unevidenced. Partial stands on better evidence. source |
| guest-loyalty-consent-management | partial, grade B - "Punchh's eClub Guest Upload endpoint documents per-channel consent primitives: marketing" | upheld | Stale-citation check. The cited slug .../b3A6NTAyODA0OTU-e-club-guest-upload 301s to the tag-scoped path .../tag/eclub/post/api2/dashboard/eclub_guests; I retrieved it under a Googlebot UA (200, 104483 bytes, full endpoint body rendered) and every quoted primitive is present verbatim - the Explicit-Opt in note, send_compliance_sms with active_registration, the validated source rule, and terms_and_conditions/privacy_policy in the request example. I also checked the guest webhook response-parameter table for a consent timestamp and found none, only marketing_email_subscription, marketing_pn_subscription, sms_subscription, unsubscribed and unsubscribe_reason. Partial stands unchanged; citation re-pointed. source |
| guest-loyalty-privacy-rights-tooling | partial, grade B - "Webhook documentation references deleted, anonymized and archived user states, implying " | upgrade-to-yes | The cell's only leg was an inference from three status names on the webhook page, and its own note conceded "no admin DSAR tooling is documented" - which is wrong. The cited URL 301s to .../webhooks-manager/events/guest; on retrieving it I found the statuses stated far more strongly ("personally identifiable information (PII) is not stored once a guest is moved into these statuses"), then searched the Platform Functions API Users group and found the tooling itself: GET /api2/dashboard/users/info locates a guest by id, email or phone and returns profile plus loyalty balance and rewards; POST /api2/dashboard/users/send_user_details_export emails a guest export to the guest and the requester; DELETE /api2/dashboard/users offers delete_general or anonymize_forget_me, the latter documented as deleting all PII while retaining anonymized transaction data "in compliance with GDPR/CCPA standards". All are business-admin-key operations the operator holds. Access, export and deletion with propagation into loyalty records are each documented, so the claim clears yes at grade B. source |
| commercial-export-customer-and-loyalty | partial, grade B - "Punchh APIs and the Webhooks Manager guest event stream expose guest records; a bulk sel" | upheld | Stale-citation check on a differentiator. The cited slug 301s to .../webhooks-manager/events/guest; I retrieved the destination (200, 94041 bytes) and it carries the complete guest JSON payload and response-parameter table, so the positive half of the note survives at the new URL. Hunting for the bulk export the note asserts is absent, I enumerated the Platform Functions Users group and found only per-guest operations - users/info, send_user_details_export (delivered by email), extensive_timeline, redemption, ban, deactivate, delete - with no list or bulk-download endpoint; the Mobile API endpoint index has no export group. Gift-card liability remains undocumented on the admin side. The value is right and now rests on a retrieved enumeration rather than on an unsupported assertion of absence. source |
| commercial-privacy-dsar-tooling | partial, grade B - "The developer portal's Webhooks Manager guest-event documentation (already cited elsewher" | upheld | Stale-citation check. The cited webhook slug 301s to .../webhooks-manager/events/guest, which I retrieved and which does still carry the deleted/anonymized/archived language, in a stronger form than the note quoted ("personally identifiable information (PII) is not stored once a guest is moved into these statuses"). The note's reasoning was nevertheless weak, so I replaced it: the Platform Functions Users group documents the DSAR operations directly - users/info to locate, send_user_details_export to export, DELETE /api2/dashboard/users with delete_general or anonymize_forget_me, the latter explicitly "in compliance with GDPR/CCPA standards". That is a real improvement in evidence but not a value change, because this claim also requires a published DPA: partech.com/legal/ and partech.com/data-processing-addendum/ both return 404, the partech.com privacy policy has no DPA mention or link, and punchh.com/privacy-policy/ 404s. Partial stands, with the shortfall restated as the missing DPA and the absence of any documented admin UI. source |
| reliability-offline-feature-matrix | no (grade F), uncited: No offline feature matrix is published anywhere on partech.com or the API portals. Not documented publicly. | upgrade-to-partial | Overturned. The In-Store Resilience release notes -- already quoted by six sibling cells in this record -- name what stops offline: Clocking Out, Checking Out and Cash Drawer Assignment blocked for fifteen minutes on the Backup Primary, online orders failing outright, and secondary registers showing "Waiting for connection to server" on a LAN outage, plus two stated conditions under which offline mode is not functional at all. Held at `partial` because gift cards, loyalty, refunds and manual card entry are each zero across the document. Scored with no url: cdn.parpos.com is robots-barred, so this rests on the record own 2026-08-08 reading, as its six siblings do. |
| commercial-implementation-fee-published | no (grade F), uncited: No implementation, menu-build, onboarding or training fees published. Not documented publicly. | upheld | Upheld and cited. The Services page names implementation, onboarding and configuration as service lines and publishes no figure (zero `$` in 9,603 chars); the Field Services Hourly page is a lead form with no rate; and a 736-URL sitemap census finds no pricing page anywhere on partech.com. source |
| digital-group-ordering | unknown | resolve-to-no | A nav-widget trap nearly produced the opposite reading. A word-boundary sweep for 'group order' returned 7 developer-portal documents, and on inspection ALL SEVEN are the sidebar table-of-contents rendering 'Open Group' or 'Close Group' immediately before 'Order Lifecycle' / 'Order Management' — a layout artefact, zero of them about group ordering. The verdict rests instead on the enumerated ordering contract: Cart 2.0 (8 operations) and the Ordering API (83 operations) contain no invite, join, share, participant, sub-cart, per-person cap or split-tender operation. Recorded as a floor, not a ceiling: 27 of the 28 published OpenAPI documents declare `additionalProperties: false` zero times. source |
| payments-chargeback-tooling | unknown | resolve-to-partial | Guarded against an artefact substitution. PAR OPS Recovery carries the whole dispute vocabulary — 'quick service restaurant dispute management', 'automating the otherwise-frustrating process of disputing delivery losses' — but it disputes DELIVERY-MARKETPLACE losses with DoorDash, Uber Eats and Grubhub, not card chargebacks with an acquirer, so it cannot settle this cell. The only on-point evidence is the PAR Pay gateway page naming 'chargeback tooling' in a feature list, which is a floor: no dispute list, deadline or evidence-submission workflow is published anywhere. source |
| commercial-wcag-kiosk-accessibility | unknown | resolve-to-no | Upgraded from an analyst inference to a measured absence by finding an enumeration. The PAR Technology Trust Center (SafeBase) publishes PAR's own compliance registry — CCPA, CIS Controls 8.1, EU-US DPF, GDPR, NIST CSF, PCI DSS, PCI SSF, PIPEDA, RH-ISAC, SOC 2 — with no accessibility standard listed and no VPAT or ACR in its documents index. That is the vendor stating what it certifies against. Corroborated by zero occurrences of VPAT, 'WCAG 2.1', 'conformance report', ADA, 'Section 508' and 'screen reader' across the 1,358-document corpus. source |
| hardware-selfpour-scales | unknown | resolve-to-no | A control was withdrawn on audit. The first draft cited 'sensor' as a zero-hit term; re-running the check over the eleven hardware PDFs (which the prose corpus does not contain) found one occurrence — 'A projected capacitive touch sensor and controller' in the KDS Bump Bar data sheet, a touchscreen, not a beverage flow sensor. 'sensor' was dropped and replaced with 'flow meter', 'pour spout', 'tap wall', 'keg', 'free-pour' and 'jigger', all confirmed zero over prose AND PDFs. The verdict itself rests on the peripheral catalogue being enumerated twice — six categories on the web page, three products on the data sheet — with no beverage hardware in either. source |
| guest-loyalty-offline-behavior | unknown | resolve-to-partial | Held to `partial` rather than `yes` on two grounds. First, the claim asks about lookup, accrual AND redemption, and offline redemption is addressed nowhere — Modules 9 and 10 cover check queuing and deferred earning only. Second, the framing: Module 10 is a POS API Certification tutorial written for integrators ('the POS is expected to', 'the POS should support'), so it states the loyalty platform's contract with a POS rather than describing PAR POS's own implementation. It is still the explicit queue-and-reconcile documentation the claim asks for, at grade A. source |
| extensibility-webhook-reliability | unknown | resolve-to-partial | Two of three limbs hold, the third fails, and a quotation was re-cut on audit. Signing (HMAC-SHA256 + idempotency key) and retry-with-backoff are documented twice over, in the External Orders API and again, on a different schedule, in the Punchh Webhooks Manager. No replayable event log exists: Punchh bounds log retention at 7 days and offers ping-based reactivation, not redelivery, and neither API publishes a replay or redrive endpoint. On audit the signature quotation was found to span two cells of a Markdown table (the 247th's most common fidelity slip) and was re-cut so each fragment is quoted only within its own cell. source |
| reliability-local-transaction-engine | yes (grade C, quarantined) | upheld | Re-homed off a barred host rather than re-fetched. The cell stood on cdn.parpos.com/docs/5.0nArchitectureEvolutionFAQ.pdf, quarantined 2026-08-16 under a host-wide robots bar, and had been demoted B -> C as a result. The successor documentation is on a host that permits us: developers.partech.com's parpos-cloud-apis section is the announced replacement for the legacy brinkapiportal, and its Ordering service OpenAPI document carries the same proposition at grade A — GetMasterTerminalStatus, 'Check whether the Primary Register of the location is online (connected to the cloud) or offline.' The quarantine bookkeeping was removed because the verdict no longer depends on the barred document; the barred document itself was NOT re-fetched. Note the spec is a floor for prose (27 of the 28 published OpenAPI documents declare additionalProperties: false zero times), so the operation list is the enumeration relied on here, not the descriptions' silence. This clears the cell from data/_generated/reverify-queue.json. source |
| extensibility-api-access-cost | unknown | resolve-to-no | Resolved off a surface the 2026-08-08 pass did not read. That pass looked for a price list and found none on partech.com; the answer was in the contract suite at partech.com/terms-and-conditions/, whose 19 PDF links each 301 to a /doc/<slug>/ page. PAR publishes an API Service Level Commitment that exists only for customers who "have elected to pay additional Fees based upon the number of Customer's eligible integrations to the PAR POS Services", denominates every credit in "subscription Fees for the API Services", and defines the fee base as named API account tokens. The Subscription Services Agreement and the Master Agreement each carry the charge independently in the Licensed Software definition. Scored `no` rather than `partial` because the claim is binary on inclusion. Two things deliberately NOT claimed: the fee base is per integration, not the per-location fee the claim names, and no amount is published. source |
| reporting-api-not-upcharged | unknown | resolve-to-no | Same document, and it covers data requests by name: the API SLC is "for order requests and for data requests through the API", and its section 2 API Data Request Service Level Commitment is remedied in credits against monthly subscription Fees for the API Services. So raw-data access through the API sits inside a separately-feed service. Bounded honestly: the documented fee base is per eligible integration rather than per location, and no revenue share or enterprise-only contract requirement is documented at all. The report catalogue itself is a different question and is still unresolved (reporting-tier-paywall). source |
| hardware-usable-after-churn | unknown | resolve-to-partial | Two new surfaces, and they answer everything except the sentence the claim actually asks for. The Hardware Terms state title passes to the Customer at delivery on purchased Hardware and incorporate the Microsoft embedded-OS EULA "located at Drivers and Downloads (partech.com)"; that library turns out to be public and un-gated at support.partech.com, 137 sitemap-listed downloads including per-model OPOS/UPOS drivers for every current terminal line and the Windows 10 IoT Enterprise entry; and the Subscription Services Terms section 5 enumerate the exit obligations as pay, uninstall the Licensed Software, destroy or return Documentation - hardware is not returned. Held at partial, not yes, because PAR nowhere states the terminal remains usable with another vendor's POS software after cancellation: the conclusion is inference from title, the pass-through OS licence, the driver library and the uninstall-not-return clause. Recorded against it: the PAR Pay PCI notice shows PAR can push firmware that stops a payment device processing. source |
| delivery-driver-tracking | unknown | resolve-to-partial | The prior pass's conclusion - that no PAR document describes a driver-facing app or a driver position field - was bounded to the Brink config guide, the legacy API portal and developers.partech.com, and it is falsified by a fourth surface: supportcenter.partech.com, a Salesforce Experience help centre with 1,109 sitemap-listed articles, reached via the Aura endpoint. Driver App 2.0 publishes mandatory location permissions, a 30-second-moving / 3-minute-stationary reporting cadence to the dispatching service, and a 10-minute-silence auto-offline rule; Dispatch 2.0 shows orders on a map with Google Maps ODRD named. Partial rather than yes because it is PAR Ordering's Dispatch module - "Dispatch is a PAR Ordering module" - separately licensed at market- and customer-specific pricing, not a Brink POS capability. source |
| delivery-route-map | unknown | resolve-to-partial | The map exists and the sequencing does not, on PAR's own account. Dispatch 2.0 displays delivery orders on a map and names Google Maps ODRD and HERE Tour Planning; auto-assignment groups orders into Routes by proximity and expected delivery time and recalculates on every new order. Shortfall named: no article claims stop-sequence optimization - manual route creation has the dispatcher click orders "in the delivery sequence desired" - and HERE Tour Planning is listed only as a party involved, which is not a statement that PAR optimizes turn order. Second shortfall: separately licensed PAR Ordering module rather than a Brink screen. Resisted the temptation to read HERE Tour Planning's product capability as PAR's documentation. source |
| delivery-tracking-page | unknown | resolve-to-partial | Dispatch 2.0 says the module lets an operator share the driver location with guests in both own-fleet and DSP setups, and give guests accurate pre-order estimates. Graded C, not B, because both sentences are in the article's "Why is it unique?" competitive-positioning section rather than a procedure - the distinction between a claim and a fact. Partial, not yes, because nothing in the 1,109-article corpus describes the guest-facing artefact: no order-status page article, no tracking-link article, no SMS, and no statement that it is served on the restaurant's own domain rather than in PAR's white-label app. The only guest-location procedure in the corpus runs the other way (Trip Tracking times the fire from the guest's ETA to the store). source |
| delivery-offline-behavior | unknown | resolve-to-partial | One of the claim's three limbs is now answered, in the negative and explicitly: Dispatch 2.0's conditions of use state the product requires a stable internet connection, requires drivers' phones to have one too, and the Driver App switches a driver offline after 10 minutes without location updates, at which point they stop receiving orders. So driver assignment during an outage stops. Shortfall named: cash delivery orders and driver settlement remain unaddressed in both the dispatch articles and Brink's own subsystem-organised offline documentation. Partial rather than yes on that incompleteness, and rather than no because the claim is about documentation, not capability. source |
| payments-offline-decline-liability | unknown | resolve-to-partial | The prior pass said the liability language would live in the merchant processing agreement, which PAR does not publish, and that no failed-offline-payment report exists. The reporting half is now falsified: PAR's support centre states an offline-approved transaction "will always maintain this characteristic and can be queried / reported on in StorePlace", and the same article publishes the full decline path - 3 attempts over 2 calendar days, then DECLINED and removed from processing. The liability half stands unresolved: "removed from processing" is the processor's handling, not an allocation of the loss, and neither the Sub-Merchant Agreement nor the PAR Pay SLC assigns it. Partial with that limb named, since the claim is a conjunction. source |
| order-capture-voice-ai | unknown | resolve-to-partial | The prior pass could not enumerate partech.com/integrations/ because it filters client-side, and concluded an integration directory would not be enumeration evidence anyway. PAR publishes the same roster as a support-centre article, categorised, and it has a "Voice AI" heading with exactly one name under it, Converse Now. That is PAR naming a voice-AI integrator at grade B, which is the claim's second limb. Held at partial: PAR ships no first-party voice agent, and the roster is a bare list - no channel, no certification tier, no integration reference, no statement about order injection without staff transcription. A roster row is a floor on who integrates, not a description of the integration, which is also why the two channel-specific cells (digital-voice-ai-phone, digital-drivethru-ai) were left unknown rather than moved on the same row. source |
| kitchen-all-day-counts | unknown | upheld | The prior rationale's premise was wrong and its verdict was right. PAR does publish KDS documentation - the PAR KDS Manual (770507404H / 770507413H) plus Monitor, Controller and Bump Bar quick reference guides, un-gated at support.partech.com - but they are hardware documents (mounting, cabling, touch-screen specs) and the manual itself refers the reader elsewhere for the software. The 1,109-article support centre carries KDS troubleshooting only. The KDS application's display options remain unpublished, so this stays a corpus gap rather than an absence. Note for the next pass: the one first-party Kitchen integrator PAR names is QSR Automations, whose own product does carry all-day counts - that is the partner's capability, not PAR's, and must not be scored here. source |
| digital-drivethru-ai | unknown | upheld | A new and complete drive-thru corpus, deliberately not read as absence. The PAR DT Portal User Guide v2.3 (July 2026, support.partech.com) enumerates the whole PAR Drive-Thru Cloud Management Portal across 1,229 extracted lines and contains zero tokenised occurrences of voice, AI, agent or escalation. That is not scored, because the guide's own Intended Use section bounds the product to "a monitor display view of their current drive thru car lane status along with data and metrics" - a timer and metrics system, in which a lane voice agent would not appear by construction. The support-centre roster names one Voice AI integrator without stating a channel. Unresolved. source |
| digital-voice-ai-phone | unknown | upheld | Premise corrected, verdict unchanged. PAR does name a voice-AI integrator (Converse Now, under a "Voice AI" category in its support-centre API-integrator roster), so the prior sentence that PAR has published nothing naming a voice partner is false. The roster states no channel, so crediting inbound phone ordering to it would be inventing the channel; the channel-agnostic cell (order-capture-voice-ai) was moved instead. source |
| multi-location-local-override-policy | unknown | upheld | PAR Ordering's Management Center, newly readable in the support centre, has a per-level menu override hierarchy and publishes a per-article role matrix - but it gates the opposite way from the claim, marking Store Manager unavailable for product visibility and item price and stating that Price Groups "cannot be modified on a Store level". So in PAR Ordering nothing is store-editable; in Brink POS the Settings Editor is fully per-location with corporate change pushed by Changeset Publisher. Neither is per-field override with corporate locks. Upheld unknown because the original reason is untouched: the Brink guide still does not enumerate the individual Rights inside a Role, so a field-level restriction there cannot be excluded. source |
| extensibility-api-access-cost | no / B, cited the API Service Level Commitment's "elected to pay additional Fees" scope clause plus the Licensed Software definition in the SSA and Master Agreement | downgrade-to-partial | The sweep read one document in a suite of 23 and missed the sibling that answers it. The API SLC's "elected to pay additional Fees" sentence is that SLC's own availability clause, not a gate on API access - and the base Service Level Commitment for PAR POS Services, available to every subscriber with no fee election, commits to uptime for a transaction "using a point of sale terminal or using the in-store API" and separately notes that the above-store portal SLC "does not include API Services which are separately covered by the API Service Level Commitment". So the elected Fees buy the above-store third-party-integration API, and in-store API use is inside the ordinary subscription. The Licensed Software definition cuts the same way: it GRANTS "any application programming interfaces (APIs) thereto" as part of Licensed Software and then says the customer "may be required to pay" for direct use - a reserved right, in permissive terms, with no published amount. Every quoted span was re-extracted from the PDFs with pdftotext -layout and -raw and is verbatim and contiguous; the error was reading, not transcription. A "no" here would have stated that PAR upcharges API access when PAR's own contract includes the APIs in the licensed software. The tell the sweep noted and overrode is also real: it conceded the fee base is per integration not per location and that no amount is published, which is a partial's reasoning attached to a no's value. source |
| reporting-api-not-upcharged | no / B, cited the API SLC's data-request section and the SSA's Licensed Software proviso | downgrade-to-partial | Same misreading as extensibility-api-access-cost and one more defect. The base PAR POS Service Level Commitment needs no fee election and covers the in-store API, and it is the document that tells you what the API Services fee is scoped to ("does not include API Services which are separately covered by the API Service Level Commitment"). So the documented surcharge is on the above-store third-party-integration API, not on API and raw-data access as such. The extra defect is a conjunction of unknowns: this claim covers "API and raw-data access", and the sweep's own note concedes the Admin Portal report catalogue is not shown to be metered and points at reporting-tier-paywall, which it left unknown - as it left reporting-history-retention. Neither the SSA proviso ("may be required to pay") nor the API SLC documents a revenue share or an enterprise-only contract, which are two of the three gates this claim names. Partial, with the above-store per-token surcharge as the named shortfall. source |
| delivery-driver-tracking | partial / B, cited Driver App 2.0 GPS cadence and the Dispatch 2.0 map, shortfall named as the PAR Ordering SKU separation | upheld | Value survives, basis corrected, and the shortfall the note named was the wrong one. I re-retrieved Driver App 2.0 through the Aura endpoint myself: the cadence is verbatim ("every 3 minutes when the Driver does not move and every 30 seconds when the Driver moves"), so is the 10-minute auto-offline, and so is the mandatory location permission - the figures are in the article cited, not borrowed from another. But the note then offered the Dispatch 2.0 map as the other half, and that map plots ORDERS ("consolidates all the delivery Orders in one view"), not drivers. I fetched and read every delivery article in the support centre sitemap (ten of them, including the four route articles and dispatch-performance-dashboard, which the sweep had not opened) and regexed every sentence containing map, location, GPS or position: not one shows driver position on a dispatcher screen. The only PAR sentence about surfacing driver location addresses the GUEST and sits in a competitive-positioning section. Claim capture limb met, dispatch-screen limb unevidenced - so partial stands and the note now says so. Note also that the quoted cadence spans cross <em> tags around "Driver" in the raw body; they are contiguous in the rendered prose, which is what is quoted. source |
| delivery-route-map | partial / B, map documented and turn-order sequencing not, shortfall named | upheld | Upheld on stronger evidence than the sweep had. The ODRD and HERE Tour Planning names are verbatim, and the note is right to say PAR states only that they are "parties involved" rather than claiming optimisation. The sweep's asserted zero on system-generated sequencing was unbounded - it had cached 20 of the 1,109 articles - so I enumerated the sitemap and read all four route articles. They are unanimous and they make the zero stronger, not weaker: "Here they can change the Order sequence of the Route" (how-to-edit-routes), "The sequence of Orders is saved as Draft - a sequenced list of Orders" (how-to-work-with-route-drafts), and auto-assignment is documented as grouping by expected delivery time, proximity, vehicle type and bag capacity, never as ordering the stops. The note now cites that enumeration instead of a bare zero. source |
| delivery-tracking-page | partial / C, cited Dispatch 2.0's "share the Driver location with your Clients" with the shortfall that nothing in the 1,109-article support centre describes what the guest receives | upheld | Value upheld, evidence upgraded, and the note's asserted zero was false. The sweep was honest that its two quoted sentences sit in the article's "Why is it unique?" competitive section - I confirmed that placement - and correctly graded them C. But it then asserted that nothing in the support centre describes what the guest receives, over a corpus of 20 articles it had cached out of 1,109. It does: the Catering Delivery Dispatch Module documents customer email "notifications when a driver is assigned, when the order is picked up, and when it is delivered", with "a delivery-status progress bar and customizable title and description fields", in a configuration article rather than a positioning one. That is real order-and-driver-state guest communication, so the cell is now cited to it at grade B. It is still not this claim: no branded status page, no tracking link, no guest-visible driver location, the module's SMS goes to drivers not guests, and no statement that any guest surface sits on the restaurant's own domain. Partial with a shortfall the evidence supports. source |
| payments-offline-decline-liability | partial / B, reconnect mechanics and reporting documented, liability limb not | upheld | Re-retrieved both articles through the Aura endpoint. Every quoted span is verbatim and contiguous, with one fidelity slip corrected: the note capitalised "Removed from processing" where PAR writes "will be removed from processing". The liability shortfall is real - I read the Sub-Merchant Agreement and the PAR Pay Service Level Commitment and neither allocates the loss on a failed store-and-forward upload. One over-claim tightened: the note said the reporting limb was answered, but the StorePlace sentence is about offline-APPROVED transactions retaining that characteristic, and nothing says a transaction declined on its third attempt appears in a report - which is the population this claim actually asks about. Partial stands; the shortfall now names both gaps. source |
| delivery-offline-behavior | partial / B, driver-assignment limb documented in the negative, cash orders and settlement unaddressed | upheld | The weakest-looking of the six and it holds up. "The product requires stable internet connection and Google Chrome browser" and the own-fleet requirement for smartphones "with a stable internet connection" are verbatim in the Dispatch 2.0 conditions of use, and Driver App 2.0 carries the mechanism the note infers from: a driver is "also considered offline if they close the application, the battery is out or the connection is lost", and "The Driver can set themselves offline and stop receiving Orders". So assignment stopping on a lost link is documented rather than inferred. The named shortfall is true - I searched the full article sitemap and there is no article on cash delivery orders or driver settlement during an outage - and the note does not overstate: it says PAR documents one limb in the negative and is silent on two. Worth recording that the documented outage is the DRIVER's connection, while the claim is framed around the store's; the note's "it stops" survives either way. source |
| order-capture-voice-ai | partial / B, cited the support centre's API-integrator roster where a "Voice AI" heading names "Converse Now", shortfall named as no first-party agent and a bare roster | upheld | I re-retrieved the roster article and read it in full. The "Voice AI" heading is real, "Converse Now" is the only name under it, and the adjacent readings in the note are also right ("Omnivore" under "Universal API", QSR Automations the single Kitchen integrator). On the asymmetry with digital-voice-ai-phone: it is principled, not arbitrary. This claim is satisfied in the alternative by "a documented API partner program for third-party voice AI", and a first-party, categorised, published roster of API integrators with a Voice AI category is thin evidence of exactly that structural fact. digital-voice-ai-phone asks instead for a partner that answers inbound CALLS and injects the order without staff transcription - functional predicates the roster does not touch - so unknown is right there. Held at partial and not higher for the reason the note gives: a partner-directory row is neither ceiling nor floor on what the integration does, and PAR ships no first-party agent. source |
| hardware-usable-after-churn | partial / B, title passes at delivery, Microsoft EULA passed through, 137 public driver downloads, uninstall-not-return on termination; shortfall that no document states post-cancellation usability | upheld | Every span verbatim and contiguous against pdftotext -layout and -raw, and the driver library is real and un-gated: I enumerated support.partech.com/wpdmpro-sitemap.xml myself and got exactly 137 download entries, including OPOS drivers across the EverServ, Wave, Volt, Phase, Controller, Helix and Tablet lines and both OS entries (the note compresses PAR's "Windows Embedded POS Ready 7" to "POSReady 7"; the entry exists), and the Windows 10 IoT download page returns 200 with no login. One over-read trimmed: the note offered "ParTech will create procedures that allow for third-party software installation" as confirmation that the machines take customer software, but that sentence is clause (v) Remote Deployment Scripts inside Remote Care Services - PAR's own managed service deploying customer software during the subscription, not a statement about the terminal after cancellation. The note already conceded the conclusion is inference only, and with that trim the partial is honest: the claim asks whether the vendor DOCUMENTS post-churn usability, PAR documents every ingredient and never the conclusion. source |
| digital-voice-ai-phone | unknown / F, rationale rewritten 2026-09-12 to record that the roster names a Voice AI integrator but states no channel | upheld | Challenged as the likely place a partner roster would be over-read, and it was not. The rewritten rationale is true against the article I retrieved: the roster names Converse Now under a Voice AI heading and says nothing about inbound calls, certification or order injection. Correctly refused, and correctly scored on the channel-agnostic sibling instead. Recorded as upheld against its rationale rather than moved. source |
| digital-drivethru-ai | unknown / F, rationale rewritten 2026-09-12 with a tokenised zero over the PAR DT Portal User Guide, explicitly not scored as absence | upheld | The rationale does the thing the corpus discipline asks for and then declines to cash it: it tokenises, proves the matcher on terms known present (lane, vehicle, timer, report), and then refuses to publish the zero because the guide's own Intended Use sentence bounds the product to lane metrics, so its silence is not about ordering. That is a framing-sentence check applied against the author's own interest. Verified that the guide is on support.partech.com and un-gated. Correctly left unknown. source |
| multi-location-local-override-policy | unknown / F, rationale rewritten 2026-09-12 with PAR Ordering Management Center evidence that gates the opposite way from the claim | upheld | The rewritten rationale is traceable and does not overreach. Both quoted spans are in support-centre articles ("Price Groups are set on a Store Group level and cannot be modified on a Store level" in what-are-price-groups-and-how-to-use-them; the brand-menu override sentence in How-to-Control-Product-Visibility-in-Store-Menus), and the conclusion drawn is a refusal: PAR Ordering locks stores out rather than offering per-field override, Brink stays fully per-location behind Changeset Publisher, and the original reason for unknown - the Brink guide never enumerating the individual Rights inside a Role - is preserved rather than quietly dropped. Correctly left unknown. source |
| kitchen-all-day-counts | unknown / F, rationale rewritten 2026-09-12 after finding PAR KDS manuals on support.partech.com | upheld | Checked because a newly found manual is where a zero gets published carelessly, and it was not. The rationale records that the KDS documents PAR publishes are hardware manuals (monitor, controller, bump bar) that refer the reader onward for the software, notes honestly that one of the two files will not extract because of a custom font encoding, proves its matcher on present terms, and still calls the result a gap in the corpus rather than evidence of absence. The support.partech.com documentation library is un-gated as described (137 sitemap entries, enumerated). Correctly left unknown. source |
| inventory-bar-partial-bottle | unknown, grade F | upheld | Proposed partial from the PAR OPS (Data Central) portalV2 OpenAPI spec (310th session); rejected on verification: Re-fetched and JSON-parsed 2026-09-15 (HTTP 200, 5,432,838 chars, 848 paths, 1,160 schemas; the proposal's 813/1,111 counts no longer match the live file). The cited fields exist: CountItemModel/OnHandCountItemModel carry Whole/Partial/Each UMID, Description, QWeight and Quantity; OnHandCountItemPatchModel.PartialQuantity {0..9999999}; StoreCountTemplateItemModel.PartialUMID 'Partial Unit of Measure Identifier. Type: Guid'; StoreMeasureModel.Tare 'Item measure Tare Weight'. But none of it meets either conjunct. (1) 'Partial' is a count-sheet COLUMN, not a fraction of a container. The proposal's own 'TheBar' example (the only example row, on the /v2/Counts OnHandData/PeriodData/DailyData/ShiftData responses) has WholeUM = Ounce, PartialUM = Case and EachUM = Bottle, so the 'partial' slot holds a unit LARGER than the 'whole' slot. PartnerCountModel.Type confirms the semantics: 'W = Whole, P = Partial, E = Each. Determines which UOM column the quantity is assigned to.' The proposal's MEETS sentence ('an open bottle can be counted in ounces next to whole bottles') inverts the example it cites. This is ordinary three-column multi-UOM counting that any count-sheet inventory has, and the record already credits it under inventory-unit-conversion-yields yes/A. It is not specific evidence of a bar partial-bottle capability. (2) Tare is not in any count path. The seven schemas carrying Tare (ItemUM, MeasureModel, Post/PatchMeasureModel, StoreMeasureModel x2, StoreMeasureExtendedModel) are reached only from /v2/Items/{itemId}/Measures, /v2/Items/{itemId}/RecipeMeasures and /v2/StoreItems/{id}/Measures, which are unit-of-measure maintenance. No Counts schema has a tare, weight-reading or scale property. The only weight-like count fields are the QWeight factors (1 / 0.666667 / 0.0333333), which are not physical weights. A stored tare with no count use does not establish weigh-counting. (3) So the partial shortfalls every conjunct: no scale integration (scale 9 tokens, all TempScale or the schedule boolean; scales 0), no weight-based count, no bottle-fraction entry, and no bar or liquor workflow (liquor 0, pour 0, spirits 0, beverage 0; bottle 121 is example unit names). A partial whose MEETS rests on a misread example and whose shortfalls cover the whole claim refutes itself. (4) Grade A would only describe the source type; the proposition is not in the source. The cell stays unknown/F. The existing 2026-08-08 rationale stands, and the lead is still the PAR OPS counting UI or help articles, not this spec. source |
Sources
Every URL this record cites. 134 in total.
- https://partech.com/solutions/pos-hardware/
- https://partech.com/solutions/guest-engagement-platform/online-ordering/
- https://partech.com/solutions/cloud-pos/
- https://developer.doordash.com/en-US/docs/marketplace/overview/getting_started/preferred_integrations_new/
- https://brinkapiportal.parpos.com/settings2
- https://partech.com/solutions/back-office-solutions/food-inventory-management-software/
- https://about.doordash.com/en-us/news/doordash-preferred-integrations-program-2026
- https://partech.com/solutions/payment-services/
- https://brinkapiportal.parpos.com/
- https://partech.com/solutions/back-office-solutions/restaurant-forecasting-software/
- https://partech.com/solutions/insights-and-delivery-solutions/
- https://partech.com/solutions/guest-engagement-platform/digital-experience/
- https://partech.com/solutions/guest-engagement-platform/restaurant-loyalty-software/
- https://developers.partech.com/
- https://partech.com/wp-content/uploads/2026/05/050726-PTC-Earnings-Release-Q1-2026-Final.pdf
- https://partech.com/solutions/par-intelligence
- https://partech.com/solutions/guest-engagement-platform/
- https://brinkapiportal.parpos.com/bestpracticeandfaqs
- https://developers.partech.com/docs/dev-portal-webhooks-manager/events/guest
- https://partech.com/solutions/back-office-solutions/restaurant-labor-management-scheduling-software/
- https://partech.com/solutions/back-office-solutions/
- https://partech.com/products/par-ops/
- https://partech.com/partner-ecosystem/
- https://developers.partech.com/docs/dev-portal-pos/additional-topics/make-first-pos-call
- https://status.parpay.partech.com/
- https://www.soundhound.com/newsroom/press-releases/soundhound-ai-to-acquire-synq3-to-expand-its-ai-customer-service-solutions-and-create-the-largest-voice-ai-provider-for-restaurants/
- https://www.sec.gov/Archives/edgar/data/708821/000070882126000076/aex991earningsreleasexq120.htm
- https://dc01.rmdatacentral.com/Portal1240/api/actions/index.html
- https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json
- https://dc01.rmdatacentral.com/Portal1240/api/swagger/portal/swagger.json
- https://dc01.rmdatacentral.com/Portal1240/api/swagger/shiftworks/swagger.json
- https://api.delaget.com/swagger/v1/swagger.json
- https://developers.partech.com/operations-tools/par-ops
- https://developers.partech.com/docs/dev-portal-pos/additional-topics/applepassintegrationwithpos
- https://developers.partech.com/docs/dev-portal-mobile/apis/mobile-api
- https://developers.partech.com/docs/dev-portal-mobile/
- https://developers.partech.com/docs/dev-portal-platform-functions/additional-topics/gettingstartedwithcustomsegment
- https://developers.partech.com/docs/dev-portal-platform-functions/additional-topics/campaigns
- https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api
- https://developers.partech.com/docs/dev-portal-developer-resources/punchh-api-and-product-faqs
- https://partech.com/delaget/
- https://brinkapiportal.parpos.com/sales2
- https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/eclub/post/api2/dashboard/eclub_guests
- not refetchable
- not refetchable
- not refetchable
- not refetchable
- not refetchable
- not refetchable
- not refetchable
- https://dc01.rmdatacentral.com/Portal1240/api/swagger/portalV2/swagger.json
- https://partech.com/solutions/pos-hardware/
- not refetchable
- not refetchable
- https://rmhs.rmdatacentral.com/Web1243/services/DC_Item.asmx
- https://rmhs.rmdatacentral.com/Web1243/services/DC_Inventory.asmx
- https://brinkapiportal.parpos.com/settings
- not refetchable
- https://developers.partech.com/docs/par-pay/
- https://brinkapiportal.parpos.com/ordering
- not refetchable
- not refetchable
- not refetchable
- not refetchable
- not refetchable
- https://brinkapiportal.parpos.com/kitchen
- not refetchable
- https://brinkapiportal.parpos.com/settings2#JobTypeTable
- https://brinkapiportal.parpos.com/sales2#OrderTypeTable
- https://partech.com/terms-and-conditions/
- https://partech.com/wp-content/uploads/2026/02/02-PAR_GEN-Subscription-Services-Agreement_Website-v2.0-2025-11-14.pdf
- not refetchable
- not refetchable
- https://partech.com/wp-content/uploads/2026/02/08-Service-Level-Commitment-PAR-POS-Services-v2.0-2025-11-14.pdf
- https://status.parpos.com/
- https://partech.com/wp-content/uploads/2026/02/12-Technical-Support-Services-PAR-POS-Services-v2.0-2025-11-14.pdf
- https://partech.com/wp-content/uploads/2026/02/03-Menu-Maintenance-Services-PAR-POS-Services-v2.0-2025-11-14.pdf
- https://partech.com/wp-content/uploads/2026/02/03-Terms-and-Conditions_Sale_-Hardware-Installation-AE-Services-On-Site-v2.0-2025-11-14.pdf
- not refetchable
- https://partech.com/wp-content/uploads/2026/02/04-Security-Overview-v2.0-2025-11-14.pdf
- https://trust.partech.com/
- not refetchable
- https://partech.com/doc/04-sub-merchant-agreement_stand-alone/
- https://partech.com/terms-of-use/
- not refetchable
- https://developers.partech.com/docs/dev-portal-mobile/apis/mobile-api
- https://developers.partech.com/docs/dev-portal-mobile/apis/mobile-api/tag/payment-cards
- https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/eclub/post/api2/dashboard/eclub_guests
- https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users/post/api2/dashboard/users/send_user_details_export
- https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users/delete/api2/dashboard/users
- https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users/get/api2/dashboard/users/info
- https://developers.partech.com/docs/dev-portal-webhooks-manager/events/guest
- https://developers.partech.com/docs/dev-portal-platform-functions/apis/platform-functions-api/tag/users
- https://partech.com/privacy-policy/
- https://developers.partech.com/docs/parpos-cloud-apis/soap
- https://partech.com/services/
- https://partech.com/sitemap_index.xml
- https://partech.com/wp-json/wp/v2/types
- https://developers.partech.com/sitemap.xml
- https://developers.partech.com/docs/parpos-cloud-apis/llms.txt
- https://developers.partech.com/docs/eo-api/apis/external-orders-api-2
- https://developers.partech.com/docs/dev-portal-webhooks-manager/webhook-delivery
- https://developers.partech.com/docs/dev-portal-pos/tutorials/modules/10-handling-pos-disconnections
- https://developers.partech.com/docs/dev-portal-mobile/additional-topics/implementing-sms-marketing
- https://partech.com/solutions/pos-hardware/pos-tablets/
- https://partech.com/solutions/pos-hardware/pos-peripherals/
- https://partech.com/wp-content/uploads/2026/08/PAR-Volt-Data-Sheet-080726.pdf
- https://partech.com/wp-content/uploads/2026/06/PAR-Peripherals.pdf
- https://partech.com/wp-json/wp/v2/media?mime_type=application/pdf
- https://partech.com/solutions/payment-services/payment-processing/
- https://partech.com/doc/05-service-level-commitment-api-services-par-pos-services/
- https://partech.com/doc/02-par_gen-subscription-services-agreement_website/
- https://partech.com/doc/01-par-master-agreement-consolidated-all-par-services_website/
- https://partech.com/doc/02-hardware-terms-for-master-agreement/
- https://partech.com/doc/01-subscription-services-terms/
- https://partech.com/doc/03-menu-maintenance-services-par-pos-services/
- https://partech.com/doc/12-technical-support-services-par-pos-services/
- https://support.partech.com/documentation/
- https://support.partech.com/documentation-files/par-kds-manual/
- https://support.partech.com/documentation-files/par-dt-portal-user-guide/
- https://supportcenter.partech.com/s/sitemap.xml
- https://supportcenter.partech.com/s/article/driver-app-2-0
- https://supportcenter.partech.com/s/article/dispatch-2-0-overview
- https://supportcenter.partech.com/s/article/how-to-configure-and-enable-auto-assignment
- https://supportcenter.partech.com/s/article/creating-and-assigning-routes-to-drivers-or-dsp
- https://supportcenter.partech.com/s/article/how-does-offline-store-and-forward-mode-work-other-noteable-offline-store-a
- https://supportcenter.partech.com/s/article/what-do-i-do-if-my-device-is-in-offline-store-and-forward-mode-and-it-becom
- https://supportcenter.partech.com/s/article/where-can-i-find-a-list-of-the-current-par-strategic-partners-api-integrato
- https://supportcenter.partech.com/s/article/How-to-Control-Product-Visibility-in-Store-Menus
- https://supportcenter.partech.com/s/article/how-to-edit-item-price-in-price-group
- https://supportcenter.partech.com/s/article/Catering-Delivery-Dispatch-Module
- https://supportcenter.partech.com/s/article/how-to-edit-routes
- https://supportcenter.partech.com/s/article/how-to-manage-driver-app
- https://supportcenter.partech.com/s/article/dispatch-performance-dashboard