Reconciliation Rules Overview
Reconciliation Rule Variables
To use Reconciliation Rules, you’ll need to create Expected Payments with
reconciliation_rule_variables.
Reconciliation Rules help automate the reconciliation of Transactions and Expected Payments by defining matching logic.
You can create one or more rules, likely using different rules per fund flow or bank partner. Rules are defined for your organization, and each can apply to one or more Internal Accounts.
Rules can be managed in the dashboard by Users in Roles with "Manage, Review, and Edit Access" permissions for "Accounts".
Strategy
Modern Treasury supports the three common types of reconciliation strategies, described below.
| Option | Condition |
|---|---|
| One Transaction and One Expected Payment | The amount of a Transaction must equal the amount of a single Expected Payment to reconcile. For example, a $100 Transaction reconciles to a $100 Expected Payment. |
| One Transaction and Many Expected Payments | The amount of a Transaction must equal the sum of the amount of a group of Expected Payments to reconcile. This strategy is commonly used to reconcile payments that settle as a batch, such as ACH or credit card payments. For example, a $100 Transaction reconciles to a group of three Expected Payments with amounts of $10, $20, $70. To use this Strategy, you will also need to specify how to group the Expected Payments. All Expected Payments in the group must have already been created at the time of evaluation. |
| Many Transactions and One Expected Payment | The sum of the amounts of multiple Transactions must equal the amount of a Expected Payment for the Expected Payment to be reconciled. This strategy is commonly used to reconcile payments that settle as multiple transactions over a period of time, such as with payment installments. For example, you receive a $25 Transaction each week for four weeks. All four of these Transactions reconciles to an Expected Payment with an amount of $100. As soon as the first Transaction is linked to the Expected Payment, the Expected Payment will become partially_reconciled.To be eligible for this strategy: • The Expected Payment must have a set date range • The matching Transaction must have occurred within that date range (i.e., Transaction as_of_date is between Expected Payment date range)• The matching Transaction amount must be less than or equal to the remaining unreconciled amount on the Expected Payment. |
Expected Payments can be
partially_reconciledAn Expected Payment is
partially_reconciledif the sum of the amount(s) of its reconciled Transaction(s) is less than the amount of the Expected Payment. It becomesreconciledonce the sum of the amounts of its reconciled Transactions equals its amount.Rules with the many Transactions and one Expected Payment strategy will automatically set and transition Expected Payments from
partially_reconciledtoreconciledas it matches all its Transactions.For example, a $100 Expected Payment becomes
partially_reconciledwhen its first matching $25 Transaction is reconciled. It becomesreconciledonce the fourth $25 is reconciled to total $100 of Transactions.
Conditions
Conditions describe what needs to be true for Transaction(s) and Expected Payment(s) to reconcile.
You can create one or more conditions, grouped into condition blocks. Conditions and condition blocks can be combined using AND or OR.
Each condition is expressed as a field, operator, and value combination.
| Type | Description |
|---|---|
| Field | Valid parameters of Transactions or Expected Payments (see full list). For example, Expected Payment Start Date, Transaction Type. |
| Operator | How the field and value will be compared. The available operators depends on the field chosen. For example, equals, greater than, contains. |
| Value | Valid parameters of a Transaction or Expected Payment (see full list). Or a fixed value such as a number, date, string. |
Example 1: Condition with fixed value
This means that this Reconciliation Rule will only apply to Expected Payments that are USD currency.
Example 2: Condition comparing data parameters
This means that to reconcile, the Transaction payment type must be equal to the Expected Payment payment type.
Expected Payments parameters are expressed as an array using reconciliation_rule_variables to handle variability and uncertainty of payments (see API reference). So it is possible to match on multiple values.
Custom Identifiers
You can use specific remittance information for reconciliation such as an invoice number, counterparty name or reference number.
First, add the remittance information as customer_identifiers when creating Expected Payments using the reconciliation_rule_variables array (see API reference).
Then, when creating the reconciliation rule condition, reference the Expected Payment Custom Identifier as a field or value.
For each Expected Payment, you can specify up to 20 reconciliation_rule_variables, each of which can have up to 50 custom_identifiers, and each custom_identifier has a 100 character limit.
Priority
Rules are evaluated sequentially, starting with the first rule and finishing with the last rule.
It is important to order rules deliberately because the ordering affects reconciliation results. Typically it is best to have very specific rules that are unlikely to result in matching errors as your highest priority rules. For example, a rule that matches based on a unique identifier such as an invoice number. You can create broader rules that are more likely to have errors to help catch exceptions. For example, a rule that matches based on date and amount.
You can drag and drop a rule to change it's priority.
Updated about 1 month ago