Payment Flows
Last updated
Last updated
A Payment Flow is a structured representation of the flow of funds across multiple sources of transactions. It outlines the financial or operational relationships between transactions. This flow is composed of three types of transactions:
Expectation Transactions - Represent the anticipated movement of funds, which may be an actual transfer or the absence of one.
Satisfaction Transactions - Represent the actual outcome of the expected transaction (whether funds moved or not).
Informative Transactions - Provide context or supplementary information about the flow but do not directly impact the financial state.
A Payment Flow is considered satisfied when the full amount of the expectation is accounted for, either through the actual transfer of funds or a clear explanation of why it did not occur.
An Expectation is a projection or prediction of a transaction that is expected to occur. This can take the form of an actual transfer of funds or a situation where no funds are transferred but must still be explained.
Example 1: A payment is initiated, creating an expectation that funds will be settled. When the settlement occurs, the expectation is satisfied.
Example 2: If a payment is initiated but then rejected or returned (i.e., no funds are transferred), the expectation is still satisfied because the full amount has been explained.
A Satisfaction occurs when the Expectation is fulfilled. This happens in one of two ways:
Full Transfer of Funds – The expected transfer occurs.
Explanation of Non-Transfer – If no funds are transferred (like in a rejected payment), but the reason is clear and justifiable, the satisfaction is also met.
Under The Hood
A Payment Flow is essentially a graph with the following elements:
Nodes - Represent Sources (or subsets of transactions from those sources) that participate in the flow.
Edges - Represent Matching Rules that define the relationships between transactions.
The Matching Rules determine how transactions relate to each other. For instance, a sale from one system might correspond to a settlement in another, and these are linked together via matching logic.
A basic Payment Flow could be a simple one-to-one relationship between an expectation and a satisfaction. This could be a simple invoice matched to a payment.
An Aggregate Payment Flow allows for many-to-one or one-to-many relationships. This is useful when multiple smaller transactions need to be reconciled against a single larger transaction or vice versa.
Note: The “many” side (e.g., sales) will be aggregated and compared against the “one” side (e.g., a single bank settlement). If the amounts match within a defined tolerance, the Payment Flow is considered satisfied.
Example
An e-commerce company makes sales on Magento, collects payments via Stripe, and settles those funds into a Wells Fargo bank account.
Expectation: Each sale on Magento creates an expectation for funds to be transferred to Wells Fargo.
Satisfaction: When Stripe settles the funds into Wells Fargo, the settlement is compared to the aggregated total of all the sales on Magento.
Matching Rule: The sum of all Magento sales is matched to the Stripe settlement into Wells Fargo. If they match (or are within a predefined tolerance), the Payment Flow is satisfied.
A Payment Flow is considered complete when all nodes (transaction sources) and edges (matching rules) are present and accounted for. Upon completion, Ledge calculates the following:
Sum of Expectation Transactions
Sum of Satisfaction Transactions
These ratio between those two sums is the Score, which measures the alignment between the expected and actual transactions:
If the Score is 100% then the expectation is fully explained, and the flow is satisfied
If the Score is 0% then none of the expected amount is explained
Values in between indicate that some portion of the expected amount is explained
Each transaction (both expectation and satisfaction) receives this score as a metric of how the flow explains the full amount.
Note: the amount field used for the score calculation is configurable (for records that include multiple amount fields, e.g. fee, tax, etc.).
In some cases, an exact match between expectation and satisfaction is unlikely (e.g., in scenarios involving currency conversions). Payment Flows can define tolerance thresholds to determine what constitutes a “satisfied” flow. For example, if the tolerance is set to 99%, and the flow explains 99% of the expected amount, it is still considered satisfied. This is especially relevant in cases where FX rates are involved, as converted amounts may have slight deviations due to rounding or rate fluctuations.
