Updated: December 5, 2023

SAPUI5 Version 1.104

Matching

Intro

While manual matching is very time-consuming for users, intelligent systems can significantly speed up matching decisions by using AI methods, such as machine learning. The system presents one or more strategies for linking similar objects, and indicates the quality of each strategy. Users then only need to approve or reject the suggestions, or adjust them to their needs.

When to Use

Matching is relevant when at least two artifacts can be linked together on the basis of similar characteristics. The process of matching follows a set of rules, which can be adjusted dynamically (“learned”) by the system. The learned rules can change over time due to user input or other triggers.

Matching can be applied to different content types, including:

Content Type	Examples
Text	Search and replace
Images	Find all dogs in a set of pictures
Audio	Natural language processing, when an audio stream is matched to a query
Video	Find out which company logos appear during a football game, and how often
Complex business objects	Matching an invoice to goods receipts; finding a business partner duplicate

The content to be matched strongly influences the type of output and its presentation.

Match Quality

A key aspect of matching is the quality of a match. Objects can be a full match or only a partial match:

A full match is given when all defined parameters fit.
In a partial match, only some of the required parameters fit.

The more parameters match, the better the quality of a match.

Matching Types

Based on enterprise use cases, we have defined the following matching types:

Relationship matching logically connects objects of different types.

Example: Multiple invoices are matched to one payment.

Compatibility matching matches objects of different types but with shared properties to form a complete system.

Example: Assembly of a high/medium/low-end computer. A computer consists of several components such as mainboard, CPU, memory, display, and so on. All the components must be compatible. For instance, the CPU fits only on mainboards with a specific socket.

Similarity matching merges similar objects of the same type into one (also known as “golden record”).

Example: Multiple similar business partner records can be merged into one, since they all represent the same partner.

Levels of Automation

For all the above matching types, you can apply different levels of automation, from minimal to maximum automation. One exception is the manual matching use case, which has no support from an intelligent system.

We have identified the following three automation levels for intelligent matching:

Level 1: The user can select several items and check their match quality on demand.

Level 1: Select, validate and rate

This is the first level of automation for an intelligent system. Matching is still manual and user-driven, but the system verifies and rates the match quality on demand. The user can then decide to apply the match, or refine it further.

Level 2: The system presents different matching strategies and proposals, which have to be reviewed and adjusted.

Level 2: Explore and adjust

The system shows proposed matches based on different strategies. In this case, users pick one strategy, but often have to adjust.

Level 3: The system proposes high-quality matching groups, which can be easily reviewed and approved at a glance.

Level 3: Review and decide

The system generates optimal matches and presents ranked recommendations. The user reviews the proposals and picks one option without further adjustment.

Components

Matching involves a group of items that are linked by certain criteria (such as similarity or the type of relationship). This is called a matching group.

Matching Group

The following matching group characteristics are typical for the use cases we observed:

Group name: A meaningful label for the matching group. For example, this could be the name of the master record in a merging scenario, or the name of the matching criterion.
Group summary: An optional description of the group contents. The summary can be presented as a text or using key/value parameters.
Group size: The number of items in the group.
Quality indicator: Rates the confidence of matching proposal in relation to the defined goal. For example, this could be the similarity of business partner records when merging duplicates, or the percentage covered when matching invoices.
Finalizing action: An action that can be applied to the whole group, such as approval of a matching proposal.

You can present the set of matching groups to users in different ways (for example, as a list, grid, or even as a graph). Users can then drill down into a specific group and analyze its content and match quality in detail. The presentation of a matching group depends on the use case and can vary from a simple list to a chart (such as a network graph).

Behavior and Interaction

Depending on the matching level and the match quality, the degree of interaction with the matched objects and groups varies. For example, if the matching proposal is not very accurate, then editing the matching group is an essential part of the interaction.

Higher levels of automation already present good enough match proposals, and differ only by strategy. Here, the following main or finalizing actions are possible:

Approve: The proposal is accepted as it is.
Reject: The proposal is fully or partially rejected. Partial rejection involves editing the matching group manually and then accepting it. Rejection can lead to a follow-up feedback mechanism (implicit or explicit).
Merge: Involves merging two or more groups into a “golden” one.
Split: Involves creating two or more groups out of one. This can be achieved by selecting individual items, which then are used to create new groups.

Responsiveness

The concept itself does not have any limitations with regard to Responsiveness. It makes use of the standard SAP Fiori controls and floorplans and inherits their responsiveness characteristics and guidelines.

Example

The following example shows how the system creates matching proposals for unassigned payments that it was not able to clear against invoices automatically.

Using machine learning algorithms, the systems “works” through the open invoices and makes several matching proposals for open invoices that correlate with the customer payment.

These different proposals can be described as applied strategies, which define the criteria for matching.

Matching proposals for unassigned payments using matching groups

Each proposal is a matching group, which contains several invoices for the uncovered payment (one-to-many relationship). It also includes a human-readable explanation of the main parameters that were considered when constructing the matching proposal.

An example of a matching group "Least Remaining Balance"

Top Tips

Display matching groups with a set of characteristics, as described above, and present them to the user as a recommendation for approval.
Rank matching groups by priority or by confidence level, depending on the use case.
Always offer the user an explanation to outline why the system generated the suggestion in a certain way. The user needs to understand the suggestion and must be able to edit it to make minor adjustments.
Every action or decision on a suggestion must be reversible and adjustable. The user must always have the option to match items manually if none of the suggestions are suitable.

Helpful Questions to Ask

What is the desired result of the matching or merging interaction? Do you want to create a new relationship (such as a cleared document), or a new object (such as a merged contact)?
Background: Depending on the use case, we differentiate between matching (changing a relationship) and merging (changing an object).
What are the typical criteria for building matching groups?
Background: We have observed that users normally work with a set of objects that are grouped by specific criteria (matching group).
What are the typical operations users perform on matching groups?
Background: We assume that there are standard operations, such as Add Item to Group / Remove Item from Group, Split Group, Merge Groups.
What is the finalizing action for solving the issue?
Background: Depending on the use case, we assume that there is one finalizing action for each matching group (for example, Clear Invoices, Merge Contacts).