Using Transaction Matching

Transaction Matching (TRM) allows you to allocate or match together transactions on an account and enables you to automate the allocation/matching process. You define two types of rules for the matching process:

  • selection criteria - which determine the transactions considered for matching
  • match criteria - which are the fields that must match for transactions to be allocated together.

You can choose to post the allocations automatically, or to simply report on them. You can also choose to report on:

  • any transactions that fall within your selection criteria and remain unmatched
  • all unmatched transactions, unmatched debits, and unmatched credits
  • all the matched transactions.
Note: If you are using expenditure checking, the transactions are posted during Transaction Matching even if budgets are exceeded.

Transactions allocated during Transaction Matching are assigned account specific allocation references.

As part of Transaction Matching, any resulting discount and gain/loss transactions are posted to the ledger. You can also use Business Rules to set or validate analysis codes on the transactions generated by this process. To do this, create an Event Profile in Event Profile (EVP) that checks for a Function Code of Transaction Matching, and use a Call Point of either 00015 Populate or 00016 Validate Analysis on System Generated Transactions.

  1. Specify this information:
    Currency Identifier
    The currency value type to be matched. You can match transactions by base currency, transaction currency, or fourth currency. If you match by transaction currency, the corresponding base currency amounts must also be equal before an allocation is made. If the difference is caused by an exchange gain or loss, a journal is generated automatically to post this difference to the realized gain or loss account. See' Matching in the Transaction Currency'.
    Account Type
    The type of accounts for which transactions will be selected for matching.
    From/To
    The account, or range of accounts, to be selected within the account type chosen. Transactions for these accounts, matching the selection criteria, are considered for matching and allocation. Leave these fields blank to include all accounts of the chosen type.
    Note: Closed and suspended account codes are excluded from Transaction Matching.
    Selection 1-3
    This option allows you to identify up to three selection criteria which transactions must meet before they are picked for matching. If you leave all three selection criteria blank, you will select all of the unmatched transactions for the selected accounts, for periods up to the selected Cutoff Period. See 'Selecting Accounts and Transactions for Matching'.
    From/To 1-3
    A code, or range of codes, within the chosen selection criteria. Transactions are only selected if they include this range of codes. For example, you may wish to restrict the transactions to those for a range of analysis codes.
    Match Criteria 1-3
    You can select up to three different match criteria. The criteria selected will determine the basis for matching transactions to each other. See 'Defining the Transaction Matching Criteria'.
    Cutoff Period
    A cutoff period can be identified beyond which, transactions are not considered for matching. The default is to select the current period as the cutoff period.
    Report Unmatched
    This option enables you to determine the reporting detail you require for transactions that have been selected, but remain unmatched, after a transaction matching run. You can choose not to report the unmatched transactions at all, to report unmatched debit and credit transactions, only unmatched debits, or only unmatched credits.
    Report Matched
    This determines whether or not the transaction matching report identifies the matched transactions.
    Post Transactions
    This determines whether or not the allocations and any resulting discount and gain/loss transactions are posted to the ledger. If provisional postings are optional, you can choose to post the transactions as provisional or permanent.
    Input Discount Account
    This is the account to which settlement discount generated on creditor/payables accounts, or sales transactions on a client account, will be posted. See 'Applying Discounts in Transaction Matching'.
    Output Discount Account
    This is the account to which settlement discount generated on debtor/receivables accounts, or generated on purchase transactions on a client account, will be posted. See 'Applying Discounts in Matching'.
    Discount Tolerance
    The discount tolerance identifies the acceptable difference between the amount of discount allowed, as identified by the settlement terms, and the actual discount amount taken. The tolerance is entered either in the form 9999.99 to specify a fixed amount tolerance, or in the form 999.99% to specify a percentage tolerance from the calculated discount. Leave the field blank if no tolerance is required. See 'Applying Discounts in Transaction Matching'.
    Note: Discount only applies if you are matching transactions on debtor, creditor or client accounts.
    Realized Difference Account (Gains or Net)
    This field is required if you select transaction currency matching in Currency Identifier and you are posting transactions, rather than reporting on them. When transactions are matched based on transaction currency, the base currency values must balance. Consequently, gains/losses may be generated. See 'Matching in the Transaction Currency'.

    Currency Identifier is also required if you select base currency matching and Value 3 or Value 4 are defined to enforce balancing. That is, when the Currency Amount Balancing option is set to Manual or Automatic on the Value 4 tab, or Automatic on the Value 3 tab of the Business Unit Setup.

    The Exchange Gain/Loss Post Rule setting in Ledger Setup (LES) determines the use of this account. If the Exchange Gain/Loss Post Rule is set to:

    • Net Gains and Losses, enter the net realized difference account.
    • Gains and Losses Separately, enter the realized gains account. In this case, you must also enter the Realized Losses Account in the field below.
    • Gains Only, or Losses Only, the effect on Transaction Matching is exactly the same as for Gains and Losses Separately. Therefore, enter the realized gains account, and then enter the Realized Losses Account in the field below.

    You can also enter a '-' hyphen in this field, for the Base or Reporting amount exchange gain/loss to be posted to the account codes specified in Business Unit Setup. If Value 3 is Second Base Currency, the balancing account on Business Unit Setup is used. However, the gain/loss difference on the other currencies is generated into the gain/loss account defined in Currency Codes (CNC), Currency Period Rates (CNP), Currency Daily Rates (CND), or at run-time entry.

    Realized Losses Account
    This field is required if you select to match in the transaction currency and the Exchange Gain/Loss Post Rule in Ledger Setup (LES) is set to Gains only, Losses only, or Gains and Losses Separately. Any realized exchange losses are posted to this account. See 'Matching in the Transaction Currency'.
    Posting Period
    The period to which transactions generated during Transaction Matching are to be posted. Leave this blank to post to the current period. This is only required, if you selected Yes in the Post Transactions field.
  2. Save your changes.