Beta
POS Ingestion Matching is currently in beta. For more information, contact R365 Support.
POS Ingestion Matching controls how R365 identifies and matches incoming POS items to existing records during import. It introduces two behaviors that work together: POS system scoping, which isolates each POS system's records from other systems, and configurable matching identifiers, which let admins choose the field each POS system uses to match items during import.
Previous Behavior: Name-Based POS Item Ingestion
Previously, R365 ingested POS items and merged them based on name alone. This means if multiple POS items share the same name (for example, No Cheese), R365 merged them into a single POS item in R365. It did not consider that identically named POS items may belong to different dishes or represent different ingredients or portions. This led to inaccuracies in mapping and depletion tracking, particularly when items that appear the same name are actually used in different Item contexts.
Previous Behavior Example
All POS items merge based on name.
For example, the No Cheese modifier for Salad and Pizza merges into a single POS item.
Because the system treats both modifiers as the same POS item, they link to the same menu item, recipe, and purchased item. As a result, selecting No Cheese for either Pizza or Salad reduces mozzarella inventory.
This behavior causes an issue because No Cheese does not mean the same thing for both items. On Pizza, it means no mozzarella. On Salad, it means no feta. However, the system does not distinguish between these differences.
POS System Scoping
POS system scoping assigns ownership of each POS item record to the POS system that created it. During import, R365 only matches incoming items against records owned by the current POS system. Records owned by a different POS system are not considered.
If an incoming item matches an existing record that belongs to a different POS system, R365 creates a new record for the current system instead of updating the other system's record. Multiple POS systems can each own a separate record for the same logical item. Those records can each link to the same menu item for reporting and reconciliation without interfering with each other.
POS system ownership is assigned automatically during import. It is not configurable.
POS System Scoping Example
An organization operates some locations on Toast and other locations on Square. Both POS systems have a modifier called No Cheese. With POS system scoping:
When Toast runs its import, R365 creates or updates a No Cheese record owned by Toast. When Square runs its import, R365 creates or updates a separate No Cheese record owned by Square. Neither import can affect the other system's record.
Both records can be mapped to the same menu item. Sales from Toast locations and Square locations roll up to the same menu item in reports, but each POS system maintains its own record with its own data.
What Happens to Existing Records
When this feature is first enabled, existing POS item records do not yet have a POS System value. Ownership is assigned through the first import after enablement:
When an incoming item matches an existing record, it will be matched to that existing record rather than creating a new one.
The POS System field on the existing record is populated.
The Matching Identifier value is updated if needed.
Future imports from the same POS system continue to update that record.
If a different POS system later imports an item that matches an already-owned record, R365 creates a new record for that system instead of overwriting the existing one.
Configurable Matching Identifiers
The matching identifier is the field R365 uses to look up an existing POS item record during import. By default, R365 matches by Name. Admins can configure a different identifier per POS system from the POS system settings page.
The available options depend on the data each POS system provides:
Name — always available. R365 matches the incoming item to a record with the same name within the current POS system.
POS ID — available for POS systems that provide POS ID values. R365 matches the incoming item to a record with the same POS ID within the current POS system.
PLU — available for POS systems that provide PLU values. R365 matches the incoming item to a record with the same PLU within the current POS system.
Available identifier options vary by POS system based on the data each integration provides. Only options supported by the connected POS system appear in the Matching identifier field in POS system settings. When a POS system supports only Name, the field is read-only.
When POS ID Is the Matching Identifier
A Toast POS system is configured to match by POS ID. The system already contains an existing POS item record for No Cheese (POS ID: 123) linked to Toast. Two items are imported: No Cheese (POS ID: 123) and Add Cheese (POS ID: 124).
R365 searches for existing Toast records using each item's POS ID:
No Cheese (POS ID: 123) — R365 finds the existing record with POS ID 123 owned by Toast and updates it. No new record is created.
Add Cheese (POS ID: 124) — R365 finds no existing Toast record with POS ID 124 and creates a new POS item record.
When PLU Is the Matching Identifier
A Toast POS system is configured to match by PLU. The system already contains an existing POS item record for Cheese Pizza (PLU: 4001) linked to Toast. Two items are imported: Cheese Pizza (PLU: 4001) and No Cheese Pizza (PLU: 4002).
R365 searches for existing Toast records using each item's PLU:
Cheese Pizza (PLU: 4001) — R365 finds the existing record with PLU 4001 owned by Toast and updates it. Even if the item name changed in the POS system, R365 still finds the correct record using the PLU.
No Cheese Pizza (PLU: 4002) — R365 finds no existing Toast record with PLU 4002 and creates a new POS item record.
Fallback Behavior
When the configured matching identifier is missing on an incoming item, R365 falls back to Name matching for that item. This is expected behavior, not an error.
The Identifier field on the POS item record shows which field was actually used during import — including when a fallback occurred. This field is also visible in the POS Items grid. Admins can use it to identify items where the configured identifier was not available.
Fallback Behavior Example
A Toast POS system is configured to match by POS ID. During import, two items arrive:
Item 1 — No Cheese (POS ID: 123). R365 finds the configured identifier (POS ID) on this item and uses it to search for a matching record within the Toast system. The Identifier field on the resulting record shows POS ID.
Item 2 — Add Cheese (no POS ID). R365 cannot use the configured identifier because none is present. It falls back to Name and searches for a record named Add Cheese within the Toast system. The Identifier field on the resulting record shows Name, indicating that fallback occurred.
The fallback applies to that one item only. The POS system's configured identifier setting is not changed.
FAQ
What happens if an incoming POS item doesn't match any existing record, even after falling back to Name?
This scenario isn't documented. Based on the matching behavior described, an unmatched item likely creates a new POS item record owned by the importing POS system, but this article doesn't confirm that outcome or describe any related review step. Check the POS Items grid after an import to verify how unmatched items were handled, and contact R365 Support if an expected match didn't occur.
Is POS system scoping something I can turn off or configure per POS system?
No. POS system scoping — which keeps each POS system's records separate — is assigned automatically during import and is not configurable. This is different from the matching identifier, which admins can set per POS system on the POS system settings page. Scoping controls record ownership; the matching identifier controls which field is used to find a match within that ownership boundary.
How do I know if a fallback to Name matching happened during import?
Check the Identifier field on the resulting POS item record, which is also visible in the POS Items grid. It shows which field R365 actually used to find the match — including cases where the configured identifier (POS ID or PLU) was missing on the incoming item and R365 fell back to Name for that item only. A fallback does not change the POS system's configured identifier setting going forward.
What happens to my existing POS item records the first time I enable this feature?
Existing records don't yet have a POS System value assigned. On the first import after enablement, R365 matches incoming items to those existing records instead of creating duplicates, populates the POS System field on the matched record, and updates the Matching Identifier value if needed. After that first import, ownership is set and future imports from that same POS system continue updating the same record. See POS system settings for configuring the matching identifier before that first import.
Can I change a POS system's matching identifier after go-live, and what happens to already-matched records?
This article doesn't address changing the identifier after initial setup or what happens to records matched under a previous identifier. Available identifier options depend on what the connected POS system provides, and the field is configured on the POS system settings page — confirm with R365 Support before changing an identifier on a system with existing matched records.