Expected Payment to Transaction Mapping
Learn how expected payment attributes are mapped to corresponding transaction attributes
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, 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.
Updated 3 days ago