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.
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.
