Expected Payments

Create an Expected Payment to represent and reconcile a payment that you expect to receive or send (e.g., an invoice). The details specified are used to automatically match and reconcile to transactions from your financial institution.

📘
Payments sent with Modern Treasury using a Payment Order will be automatically reconciled – you do not need to create an Expected Payment in this case.

The table below details the expected payment attributes and corresponding transaction object attributes that are used for matching purposes.

Expected Payment Attribute	Description	Transaction Attribute
direction string	The direction money is flowing in the expected transaction. Either credit or debit.	direction
internal_account_id string	The ID of one of your organization's Internal Accounts where you expect to receive the payment.	internal_account_id
amount_upper_bound int32	The highest amount that the expected payment may be equal to. It is an inclusive bound.	amount
amount_lower_bound int32	The lowest amount that the expected payment may be equal to. It is an inclusive bound.	amount
type string	The expected payment type. Supported types: ACH, BECS, Bacs, Book Transfer, Card, Cross Border, Check, EFT, Interac, ProvXchange, RTP, SEN, SEPA, Signet, Wire.	type
counterparty_id* string	The counterparty, or entity (a person or business), that you expect to receive money from. Note: A counterparty must have a linked bank account in order for it to be used for matching.	vendor_description, details Varies by payment
currency string	The expected currency of the payment. Must conform to ISO 4217.	currency
date_upper_bound date	The latest date that you expect the payment may arrive.	as_of_date
date_lower_bound date	The earliest date that you expect the payment may arrive.	as_of_date
statement_descriptor* string	The statement description that you expect to see on the transaction. For ACH: full line items passed from the bank For Wire: the OBI field on the wire. For Checks: the memo field.	vendor_description, details Varies by payment

*Smart matching
The counterparty_id and statement_descriptor fields are unique in how they are used for matching:

Counterparty: we retrieve the counterparty’s bank account details such as account name, account number, and routing number. Depending on the payment type, we perform “fuzzy” matching or “contains” matching against originator and beneficiary names found in the transaction and its metadata. Routing numbers use an exact match against the sender or receiver routing number.

Statement descriptor: depending on the payment type, we perform a “contains” match of the information specified in the Expected Payment against the full line items, OBI field, or memo field of a transaction and its metadata.

How the matching engine works

To achieve high accuracy and minimize incorrect reconciliations, Expected Payments will only reconcile to the transaction if all of the defined attributes are matched. If you specify a counterparty on the expected payment, it must have a linked external account or virtual accounts for it to be considered for matching – otherwise, it will be ignored and not used for matching.

When multiple Expected Payments match the details of a transaction, they won't be automatically reconciled. Instead, these exceptions will be flagged for manual reconciliation to ensure accuracy.

Example matches

ACH transaction:

Wire transaction:

Which fields are most useful for matching

While we recommend providing as much detail as possible when creating an expected payment, some fields are more helpful than others when it comes to matching to a transaction. The utility of the different fields can vary by use case. In the case of a Capital Call for example, investors may send wire payments for the same amount over the same time period – reducing the utility of the amount and date ranges. But the statement description field could be very helpful in that case if clear instructions are provided to (and followed by) the counterparty.

Amount or Amount Range
If known ahead of time, specifying the exact amount of the expected payment is helpful for matching. However, certain variables such as fees, taxes, and even currency fluctuations can alter the amount you expect to receive. In that case, it’s best to specify the amount range (amount_lower_bound - amount_upper_bound) that you expect the payment to fall within. This built-in flexibility can be very useful when it comes to matching bank transactions where the exact amount may vary.

Expected Date or Date Range
Even payments with strict due dates can be late. Specifying a date range for an expected payment is a great way to build in fault tolerance for payments that arrive later than expected. If a given payment doesn’t have a due date, then you may want to specify a generous date range to increase the likelihood of a match.

Statement Description
The statement description field is a free form text field, allowing it to be both unique and specific. This provides a great opportunity for matching expected payments to transactions. However, it requires an exact match – meaning the string, or sequence of characters, must be identical. Therefore, it’s helpful to give clear and specific instructions to your counterparty, such as providing their full name or a unique identifier in the appropriate field of the payment (i.e., OBI field for Wire payments).