Overview

Matching determines the relationship between two sets of transactions from one or two sources. These sources are typically different, but could be the same one (e.g. a payment that was refunded may have two records that mirror each other). The rule is applied to transactions as they are ingested (see the “Ingestion” section for details) and identifies matches when specific criteria are met. Matching rules consist of two key components: audience filters and matching logic.

How Matching Rules Work

• Audience Filters: Audience filters are applied to transactions from each source independently. They select only the transactions that meet specific criteria.

• Matching Logic: Once the audience filters have narrowed down the relevant transactions from both sources, the matching logic compares them to determine if they are related.

Example:

Suppose a company wants to match its collection event records with Stripe payment transactions. Audience filters might exclude refunds or other non-sale transactions from both data sets, ensuring only “sales” collection events are compared with Stripe charges. Once filtered, the matching logic might check if the transaction numbers from both sources match to establish a relationship.

Hierarchical Rule Application

Matching rules are applied in a hierarchy, moving from the most specific to the least specific rules.

• Specific Rules: These rules might use precise identifiers, such as a transaction number.

• General Rules: If the specific rule does not produce a match, a more general (less specific) rule may be applied.

Best Practice

Use highly specific identifiers (like unique transaction numbers) when possible, since weak matching logic can be unreliable at scale. While broad rules might work with small datasets or highly unique transaction characteristics, specific rules yield more accurate matches.

Note that matching based on amounts isn’t always required. In many cases, matching can be done regardless of amounts, allowing more flexibility in the Payment Flow (see below).

Directionality of Matching Rules

Matching rules are directional, meaning they establish a relationship that takes into account the time and initiative of each transaction. However, matches can be triggered by either source. Transactions from either side can be ingested in any order, and Ledge will automatically create the match as soon as the corresponding transactions are available.

Under The Hood

When rules are applied to transactions and generate matches, they essentially generate an edge in a graph, in which the transactions are nodes. This graph later serves as the basis for much of the advanced ruling capabilities (e.g. Payment Flows) that can be thought of as queries on the graph.