# Payment Flows 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: 1. **Expectation Transactions** - Represent the anticipated movement of funds, which may be an actual transfer or the absence of one. 2. **Satisfaction Transactions** - Represent the actual outcome of the expected transaction (whether funds moved or not). 3. **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.

A Payment Flow is a multi-stage high-level representation of the flow of funds

### **Basic Components** #### **Expectation** 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. #### **Satisfaction** 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. #### **Aggregate Payment Flow** 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. {% hint style="success" %} **Example** An e-commerce company makes sales on Magento, collects payments via Stripe, and settles those funds into a Wells Fargo bank account. 1. **Expectation**: Each sale on Magento creates an expectation for funds to be transferred to Wells Fargo. 2. **Satisfaction**: When Stripe settles the funds into Wells Fargo, the settlement is compared to the aggregated total of all the sales on Magento. 3. **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. {% endhint %} #### Score 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.). #### **Tolerance in Payment Flows** 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.ledge.co/reconciliation/payment-flows.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.