Matching Identifiers for External Payments

General

For payment formats for which the payment can be matched automatically by using matching identifiers, you can define the matching identifiers in the Definition of Identifiers tab in external payment parameters. The parameters and its matching identifiers are defined per payment method, and applied to external payments that are loaded with this payment method. You can enter several matching identifiers of different types in order to define, what can be matched in general with the transactions in the loaded payment file.

For the listed payment formats below, the defined matching identifiers are considered when matching the payments.

The following information displayed in the External Payments per Load ID window can be significant for the payment matching, depending on what is loaded from the external payment file and design of the external file template:

• Original File Info, Prepared Reference
• Message Code
• Currency
• Payment Amount
• Transaction Date

For each matching identifier an identifier type is included, defining the information to be used for the payment matching.

The following identifier types are available for matching the payment with customer invoices:

• Invoice Number
• Customer Number
• Bank Account
• Identifier Reference
• Association Number
• Payment Reference
• Self Billing Reference

The following identifier type is available for matching the payment with issued checks, that includes supplier checks and customer repayment checks.

• Payment Document Number

The following identifier type is available for matching pseudo codes in order to complete a direct cash transaction automatically with a manual posting.

• Pseudo Code

Definition of Identifiers

Identifier ID

The identifier ID is the unique ID of the matching identifier within the payment method. The identifiers are used in the payment matching in ascending order of the identifier ID. This allows you to apply the matching identifiers first, which return the best match based on the matching information from the file. You can enter any number for the identifier and the numbering can be done with gaps also. This makes it also possible to change the priority of already defined matching identifier.

A possible ranking order of matching identifier are displayed below, e. g. identifiers with the highest accuracy are checked at first.

A string of the matching reference, that should be checked whether it is a check ledger item, must be of 9 digits long and the value must be between 970005000 and 970009999. Whereas the value for an instant invoice, which is checked at the end, must only be of 7 digits long and between 9700000 and 9799999. The check number interval is more accurate than interval of instant invoices.

Identifiers connected to Message Code

In general, all defined matching identifiers are used in the matching for a payment transaction. however, instead of using all identifiers, you can connect the matching identifiers to the message code and only use the connected identifiers in the matching. In order to use the connected matching identifiers for the payments, it is required to select the Only Identifiers connected to Message Code check box available in the matching options.

The advantage of this option is, that you can decide which are the reasonable matching identifiers for the message code. This set up is possible for payment formats with message codes only, and is intended for payment files, that include different types of credit and debit transactions; e.g. the MT940 payment files. You can connect matching identifiers of any type, e.g. identifier type InvoiceNo to consider only customer invoices for the payment matching.

The payment remains unmatched, if the transaction includes a message code that is not connected to a message code. This can be applicable for direct cash transaction that should not be matched at all since the account or pseudo code to use is specified in the message code.

You can connect several identifiers to one message code. The following is required, e.g., if the payment should be matched with customer invoices that belong to different series IDs. Customer ledger items includes different series ID for debit invoices, credit item, difference items etc. In the external payment parameters you can see all message codes which are connected to a single identifier. This overview informs which identifier is used for which message code in the payment matching.

Examples for transactions, for which a connected matching identifier could help to avoid to mismatch the payment:

• credit transactions that are mainly incoming customer payments
• cashing of issued checks,
• debit transactions from service providers that not are paid based on supplier invoices, e.g. electricity, gas, telecommunication provider,

Example of two MT940 transactions loaded from the same payment file and which are related to cash supplier check (line 1) and a incoming customer payment (line 2). Both include the matching reference value 9700123. For this number the customer invoice II 9700123 exists, this value is also included in the number for supplier check SUCHECK 219700123.

below are the matching identifier:

The matching results below shown whether connected identifier are used, and to which identifier the message code is connected:

In order to get the reasonable matching for the example above, the identifiers should be connected to message codes like below:

Additional Identifier

The purpose of the additional identifier is similar to the connection of identifiers to message code. The matching identifier for which an additional identifier is specified is only used, if the string entered in the additional identifier field is also included in the original file info field of the external payment transaction. The additional identifier can also be used for payment format for which message codes are used. Note: The additional identifier is case sensitive and used in the matching as defined in the identifier.

One example to use this additional identifiers is to control if the matching identifier is relevant for direct debits of service provider or other institution that not are paid based on supplier invoices, e.g. electricity, gas, telecommunication, insurances, rent etc. If the name of payment originator or receiver is included in the external file line, the name could be used as the additional identifiers. An example is described in Matching Pseudo Codes.

Use Prepared Reference

This parameter in the matching identifier defines, if for the matching identifier the original file information should be used to analyze the payment for possible matching, or if the prepared reference should be used. Both fields are displayed in the external payment details after the file is loaded. The original file line is the full text line from the external payment file from which a single payment transaction is created. This information is always available. The content of the prepared reference depends on the payment format and its connected external file template. This field can include reduced amount of information, e.g. only invoice numbers and customer number, in order to avoid mismatching the payment.

Length, Interval From/To, Label

The length, interval and label is used to extract the relevant information from the matching reference (original file info or prepared reference). The extracted information from the file is used by the matching to search for data related to the identifier type. The parameters can be used together with all available identifier types, such as InvoiceNo, PseudoCode, PaymentDocNo (for check ledger items).

You define with the length parameter the number of consecutive characters that should be extracted and checked for possible matching. The length must correspond with the data which you want to match with the payment. E.g. the invoice number in the invoice series has length of 7 digits. The length in the matching parameter should be 7 too in order to extract the relevant information completely.

Each extracted string is checked against the Interval From/To. The extracted string (e.g. invoice number) is relevant for the matching if the string is covered by the interval.

If a label is defined for the matching identifier, the string of the label is used to find the relevant information in the matching reference and the information after the label in the matching reference is extracted as the relevant information to be used for the matching. If a label is defined, the interval from/to is then optional but if specified, the extracted string is checked to see whether it is covered by the interval. When the defined string of the label is not included in the matching reference, the matching identifier will not be used to match invoices etc. Note: The label is case sensitive and used in the matching as defined in the identifier.

The advantage of using labels is to avoid mismatching of  invoices based on ambiguous information in the matching reference. E.g. the matching reference contains the information 2693337568546 INVOICE 7356854. The invoice to be matched is obviously 7356854. In case of using only the interval from 7000000 to 7999999, the payment could be mismatched if the invoice 7568546 also exists. Whether the label is applicable depends in general on the payment file and the information which is provided by the payment originators. For a label which has an invoice number, different abbreviations may exist, e.g., INV or IVC. In such case you can define several matching identifier of the same type (here InvoiceNo) and enter in each matching identifier another string for the label.

If the extracted string from the matching reference is not covered or the extracted string does not exist in the data related to the identifier type, the extracted string will not be used for the matching.

Below are examples of using length and interval in the matching identifier against the matching reference for the same row:

Example #1: The string 9700123 is extracted from the matching reference since a string with the length of 7 is 9700123 which is also covered by the interval.

Example #2: The strings 9745815 and 9745822 are extracted from the reference. After one string is found, the search continues with the next characters until the end of the matching reference is reached. I.e. if another string with the length of 7 is found which is covered by the interval, the other string will also be check for possible matching.

Examples of using length and label in the matching identifier against the matching reference in the same row:

Example #1: The string 9700123 is extracted from the matching reference since the specified label is found in the matching reference. The string with the length of 7 characters after the label is extracted. One or several possible spaces after the label are ignored.

Example #2: The strings 9745815 and 9745822 are extracted from the reference before each invoice number label is given a payment reference. The strings after the label II are extracted with the length of 7.

Example #3: Only the string 9745815 is extracted and checked for possible matching, since the label INV is only included before the first invoice number. Note: In order to match the other invoice, a matching identifier is required without a label, but with an interval.

Example #4: The extracted string is #974581 and is checked for possible matching. Normally, outgoing invoices which are created using an automatic number series do not include such #-sign in the number. If the invoice #974581 does not exists it will not be matched. A possible solution is to add another matching identifier with the label: INV #    In this case 7 characters after the #-sign are extracted and the invoice number to match would be 9745815.

Example #5: The number 9745815 after the label INV is not extracted for possible matching since the number 9745815 is not covered by the interval.

Identifier Format

The identifier format can be used to purge an extracted string before the string is used by matching the search for data in IFS/Financials.

Example: The customer's bank account in the payment file of the payment format MT940NLABN is 23.456.789 but in the application, the bank account number entered in the customer's basic data is 23456789. In order to identify the customer by using the bank account number from the file, the dots in the account number needs to be removed. By using the identifier format 99.999.999, the dots in the extracted string from the file (23.456.789) are removed and the identifier for the search is 23456789.

You can use any characters for the identifier format in order to define what should be included in the search string. The character 9 in the identifier format means, the character at the corresponding position in extracted string should be used in the string for searching for data (e.g. the single digit in the account number). All other characters in the identifier format means that the specified character should be removed from the search string, if the character in the identifier format is the same as in the extracted string at the corresponding position (e.g. the dot in the account number).

If the identifier format does not correspond to the extracted string, the whole extracted string is discarded, and cannot be used to search for data.

Example, using identifier format INV9999999

• Extracted string INV9700123 -> Identifier Format INV9999999 -> String for search: 9700123
• Extracted string IVC9700123 -> Identifier Format INV9999999 -> No string is available for the search since characters VC does not correspond with the identifier format.

Identifier Type, Series ID and Company

The identifier type in the matching identifier specifies the information, that should be matched with the payment. Below is an overview of available identifier types, and the identifiers a series ID require for the matching of ledger items.

When the payment matching is performed, the string, which is extracted according to the parameters length, interval from/to and label, is checked against the data in IFS/Financials, if data related to the identifier type exists. If you have selected identifier types InvoiceNo or PaymentDocNo, the series ID is considered to check if the ledger item exists. Ledger Items which are not used in another pending payment are matched with the payment. Pseudo codes are matched with the payment, irrespective of the pseudo code owner or whether they are used in another payment.

You can define several matching identifier for the payment. This can be required, e. g., if customer invoices of different series IDs should be considered for the matching. A mix of different identifier types can be used for payment files that includes different types of transactions, e.g. incoming payments from customers, debited supplier checks or other types of credit or debit transactions which are not related to ledger items.

The company in the matching identifier allows you to match customer invoices of another company, provided that you are associated to the other company. You can also match the payment with a pseudo code of another company, which means the other company will be debited or credited with the manual posting. The supplier checks and customer repayment checks are always matched in the payment company, i.e. a check ledger item of another company cannot be matched.

Note: When matching invoices of another company, the information extracted from the file about an invoice is generally the invoice number and the customer ID or similar information. The company ID to which the invoice belong is not available for the particular invoice in the payment file. The invoice number is checked for possible matching in the company that is specified on the matching identifier which is used to extract and to search for the invoice. When the invoice is matched finally, the invoice number from the file including the company of the matching identifier are added to the matching details. In order to match invoices of another company accurately, each company should have a different invoice number series.

Depending on the selected identifier type and the found information, the payment is matched with customer invoice(s) or with one issued check, or the payment is completed with the manual posting by the matching of a pseudo code.

Transaction Type

The transaction type for the payment is usually predefined in the external file layout and/or in the message code and set on the transaction when the file is loaded. You can also specify a transaction type in the matching identifier to override the loaded and/or manually entered transaction type of the external payment transaction when the matching function is performed. If a matching is created or a customer was found by using the matching identifier, the external transaction is updated with the transaction type defined in the matching identifier.

This automatic change of the transaction type can be used for all types of matching, i.e. for matching customer invoices, issued checks (supplier check, customer repayment check) and matching the payment with pseudo code in order to complete the payment with a manual posting. This functionality allows you to determine the type of payment based on the matching result. Note: The payment type code in the header information of the external payment restricts the possible transaction types for the payment. E.g. if the payment type code in the header is Customer Payment, only customer related transaction types such as Customer Payment, Direct Debiting, Direct Cash Transactions or cashing customer repayment checks are allowed.

When you setup the matching identifier you can define a transaction type for each matching identifier. The transaction type is optional but if specified, the allowed transaction type depends on the identifier type of the matching identifier. The possible combinations for identifier types and transaction type are:

Example:

Incoming payments can be payments for customer invoices, but also of other types of payments from payers such as a payment of rent. The default transaction type is usually customer payment according to the external file template and/or to message code. But some payments, e.g. regarding received payments of rent, requires a direct cash transaction with a manual posting.

Shown below are transactions loaded from the same payment file but not matched. The first transaction indicates that the payment is referring to an invoice, whereas the second transaction is about a received payment of rent. Note: For the matching of the payment of rent, the pseudo code AGREEMENT 2010/OFFICE is defined in IFS/Accounting Rules and includes in the account 3911.

Shown below is the set up for matching identifiers. A transaction type is defined if the payment is matched by using the pseudo code:

Note: The matching identifier used to match invoices (second line) can be defined without a transaction type, because in this example the external transactions are loaded by default as customer payment.

After the payment matching, the transaction includes transaction types and matching results in the following:

The transaction type of payment transaction #2 has changed to Direct Cash Transaction since the payment is matched with the pseudo code AGREEMENT 2010/OFFICE and the manual posting includes the account from the pseudo code. The transaction #1 is matched with the invoice.

Matching procedure

When you load the file, you can perform the payment matching instantly, if the matching option Allow Automatic Matching is selected. You can also perform the matching later, by using the matching function in the details window of the external payment. If the payment is already matched, either automatically or manually with an invoice, supplier check or customer repayment check then automatic matching is not performed on the individual transaction. The same applies to transactions for which the payer/payee is manually entered, or set by the payment matching, e.g. because of an already paid invoice which was detected in the payment file.

If the payment can be matched, the matching identifier in ascending order of the identifier ID are checked for possible matching. The following steps are carried out by the system for each matching identifier:

1. The matching identifier is checked, if it is relevant for the current payment transaction according possible connections to message codes and possible additional identifier.
2. The relevant matching reference is selected, either the Original File Line (full payment file line) or the Prepared Reference of the current transaction.
3. A string is extracted from the matching reference, based on the parameters length, interval from/to and label.
4. The extracted string is formatted according to the identifier format, if specified in the matching identifier.
5. The extracted string is checked against the data in IFS/Financials by using the identifier type, e.g. if the extracted value exists as an invoice when the identifier type is InvoiceNo used.
6. The steps 1 to 5 are repeated unless, the matching reference is fully scanned and with all matching identifiers.
   Exceptions:
   If check ledger items or pseudo codes are identified in the matching reference the matching procedure stops immediately since only one check item can be matched.
   If any invoice number is identified in the matching reference, the subsequent matching identifiers for issued checks and pseudo codes are ignored.
7. The found invoices, check ledger items and pseudo codes are analyzed in detail which of the found items can be added to the payment and the matching details or the manual posting is created. This depends on the identifier type. The proposed action, error and warning fields informs you about the matching result.
8. If the payment matching is successful, the transaction type of the external payment transaction is overridden with the transaction type of the identifier, if a transaction type is specified for the matching identifier.

Match payment with Customer Invoices

You can match the payment automatically with one or several customer invoices. This includes credit invoices and customer difference items too. The matching reference (original file info or prepared reference) is used by the payment matching to search for possible invoices and to match it with the payment.

The identifier types for matching customer invoices are:

• InvoiceNo: To search for invoices by using an invoice number
• PaymentReference: To search for invoices by using the payment reference.

For the matching with customer invoices, you can combine these identifiers with identifier types which are used to search for customers:

• CustomerNo: to search for customers by using the customer ID
• BankAccount: to search for customers by using the bank account number, defined for the payment method of external payment
• IdentifierReference / AssociationNo: to search for customer by using the identifier reference or association number.

Match invoices with single identifier

In order to match the payment with a customer invoice, it is necessary to define one matching identifier having a series ID, length and an interval. This parameters are used to find the relevant data in the matching reference and to check the invoice number found for a possible matching.

Example to match the payment with customer invoices:

The invoices below exists:

Example of using only identifier type Invoice Number (InvoiceNo) for the payment matching:

The loaded transactions below includes the payment to be matched (possible invoice numbers are underlined):

Matching Result: The payment is matched with Invoice II 9704131. Since, the matching identifier includes only the invoice series II, the invoice of the series CF is not considered when matching the payment.

Note: If several invoices are included in the matching reference, the first invoice, identified in the matching reference, determines the customer for the payment. Subsequent invoices in the matching reference are matched only, if the invoice belong to the same customer ID.

Match invoices with multiple identifiers

You can define several matching identifier for matching the payment with customer invoices. This can be necessary, if you create invoices from different series IDs. The series ID in the matching identifier is used to check if the extracted invoice number from the matching reference exists. Only invoices, that exists for the specified series ID are included in the matching of the payment. The matching identifier should include all series ID of outgoing customer invoices and customer credit items. But you can also specify the series ID of customer difference items.

Example to match the payment by using multiple identifiers:

The invoices below exists:

The matching identifiers are setup to match the payment with customer difference items of series ID CF and instant invoices of series ID II:

Matching Result: The payment is matched with Invoice II 9704131 and CF 960025. This lump sum payment includes in the matching details both invoices. The difference item of series ID CF is added to the matching first and then instant invoice of series ID II. The lump sum payment amount is applied to the matched item in the order of the matching. You can specify with identifier ID the priority of the matching the items and in which order the payment lump sum amount should be applied for which type of invoice at first.

Note: If an invoice number in the matching reference (e.g. 9700025) exists in several series IDs (e.g. II 9700025 and CF 9700025), the invoice is checked with the series ID of each identifier. Fully Paid invoices are not matched but the same invoice number (9700025) can be matched for both series IDs with the same payment transaction at a time.

Note: If several invoices are included in the matching reference, the first invoice identified in the matching reference determines the customer for the payment. Subsequent invoices in the matching reference are matched only, if the invoice belong to the same customer ID.

Match invoices with combined identifier types

You can define several rows in the matching identifier for matching customer invoices. Additionally you can define identifiers to search for customers. If you want to use matching identifier types related to customer basic data (e.g. BankAccount), you need to include the identifier type to search for invoices too. The sequence of identifiers should be first the types for customer basic data, and then the identifier types for invoices in order match invoices of the identified customer.

The example below is a possible setup to match customer Invoices of customers which are identified by its bank account.

Matching Results: The customer number is identified by using the bank account, if the matching reference contains the customer's bank account, in the specified length and covered by the interval. The invoice number is identified, if the matching reference contains the invoice number according to the interval etc. and the invoice belongs to the customer found for identifier 100.

Note: If no customer is found using the bank account, customer ID etc. the subsequent matching identifiers for invoices do not return any invoices although the invoice number is covered by the defined interval.

Note: When the identifiers for customer basic data are used in the payment matching, but no invoices could be identified using the matching identifiers for invoices, the invoices and possible credit items are added to the matching in due date order. The credit items are handled at first and invoices are included in the matching until the payment amount on the lump sum is fully used.

Match invoices of multiple companies

The company in the matching identifiers defines for which company the invoice from the matching reference should be matched. In order to match the invoice of the correct company, unique invoice number series are normally required. 

Below is a possible set up of matching identifiers for multi-company matching:

When the invoice is matched, the company to which the invoice is connected is displayed in the matching details for each invoice. In the instance, the payment is matched with several invoices of another company, the company in the external payment transaction will display the company of the matched invoices. If the payment amount of the lump sum if not fully matched, the remaining amount is posted with a new payment on account against the company displayed in the external payment transaction.

Transaction Type of matching identifier

The transactions for incoming payments from customers are normally loaded with the transaction type customer payment. You can specify the transaction type in the matching identifier in order to change the transaction type of the loaded transaction, if the payment is successfully matched with one or several customer invoices, or in the instance a customer is found. E.g. If the transaction is loaded using Direct Cash Transaction and you want to change it automatically to Customer Payment.

Currency

The payment can be matched only with invoices of the same currency and in the currency of the payment. If an invoice is included in the matching reference which has another currency than the payment currency, the individual invoice is not matched with the payment. I.e. if EUR and USD invoices are included in the matching reference, but the payment is in currency EUR, only the invoices in currency EUR are matched.

Paid invoices

Customer Invoices which are fully paid for cannot be matched with the payment. If a fully paid invoice is included in the matching reference, the invoice is not added to matching. The payment transaction will be posted as a payment on account, if all invoices of the matching reference are paid. Partially paid invoices and installments are added to the matching with the remaining amount.

Amount to match

The payment amount on the lump sum is the limit of how much can be matched with the payment. When the total of the invoice amounts has reached the lump sum amount, the invoices that exceeds the lump sum amount are included in the payment matching. For each matched invoice installment, the payment amount, discount, deduction and write-off amount is automatically calculated.

The matching option, Only Complete Matching of Payment Amount allows you to control whether matching should be performed if the the payment amount of the lump sum is fully applied to all matched invoices, (no overpayment) and, if all matched invoices are fully matched. I.e. the invoice installment has no remaining amount after the payment.

Proposed Actions

Depending on the matching result, proposed actions will be recommended for the matching results as follows:

Match payment with Issued Checks

You can match the payment automatically with one issued check by using the identifier type Payment Document Number in the matching identifier. Issued checks comprise of payment documents of type Supplier Check and Customer Repayment Check. Matching is possible only for check items of the payment company.

When you set up the matching identifier, you can specify the payment document series ID. This series ID can be either connected to supplier checks or customer repayment checks in a single matching identifier. If you create supplier checks and repayment checks using the same payment document number series, i.e. your outgoing checks are from the same number interval, it is recommended to leave the series ID empty. The payment matching will then search for checks irrespective of the series ID. With this setting you can match both types of check items by using the same matching identifier.

The check ledger item detected according to the matching identifier in the matching reference (original file info or prepared reference) is validated against the amount, currency and status. If the amount and/or currency of the identified check ledger item is not identical to the loaded transaction, or if the check is already cashed, the issued check will not be matched and a warning message will be raised. When the check is matched, the proposed action to do is, either to cash the supplier check or cash the customer repayment check, depending on the type of check item. The matched check item is displayed on the transaction directly and can be changed if necessary.

When a check ledger item is found, regardless of whether the issued check could be matched or not , the payment matching is done for the transaction, and subsequent matching identifiers of any kind will not be considered.

The transactions for cashing issued checks are normally loaded with the transaction type Cash Issued Check. This transaction type is used to cash a supplier check and a customer repayment check. The type of the check ledger item determines whether a supplier transaction or customer transaction is processed. You can specify the transaction type in the matching identifier in order to change the transaction type of the loaded transaction, if the payment is successfully matched with a check ledger item. E.g., the transaction is loaded with type Direct Cash Transaction and you want to change automatically to the type Cash Issued Check.

Supplier Checks and Customer Repayment Checks can be cashed only against the payment institute, and using a cash account from which the check item is created. A warning message is displayed when the issued check does not belong to the payment institute and/or cash account for which the external payment is created. In order to proceed with the external payment, you can create the mixed payment with the correct payment institute and cash account or you can remove the matched check item from the transaction. It is not possible to transfer the external payment to the mixed payment, if the mixed payment has another payment institute and a cash account other than the matched check item.

Check items can only be handled in one pending payment at a time. If the check item is included in another transaction or in another payment, you are also informed about this in a warning message. The pending payments should be corrected in order to proceed with the external payment.

If a transaction cannot not be matched with a check item, the proposed action will indicate that a parked supplier payment will be created. You can either change the single transaction in external payment or you can also transfer the whole load ID to the mixed payment and complete the matching.

The matching result for a transaction can include only customer invoices, an issued check or a manual posting from a pseudo code. If customer invoices are already found by preceding matching identifiers, the matching of issued checks is omitted for the current transaction.

Match payment with Pseudo Codes

The purpose of pseudo codes in the payment matching is to complete an external transaction with a manual posting automatically by using pseudo codes.

This can be used e.g. for debit transactions regarding electricity, gas, telecommunication, insurances, rent, leasing etc. which are not paid based on supplier invoices. The pseudo code should be a significant ID that is included in the matching reference and can be, e.g., a contract number of the gas/electricity provider, the car plate from car leasing, etc. The pseudo code includes the code string for posting of the costs related to the subject in the matching reference.

The matching identifiers with identifier type Pseudo Code are used to analyze the matching reference from the file (original file info or prepared reference) for possible pseudo codes which are predefined in the Pseudo Codes window in IFS/Accounting Rules. If the pseudo code, detected in matching reference, exists in the company specified on the matching identifier, then the matching is finished for the transaction and possible subsequent matching identifiers of any kind are not considered. The matching result for a transaction can include only customer invoices, issued checks or a manual posting from a pseudo code. If customer invoices are already found by preceding matching identifiers, the matching identifiers for pseudo codes are omitted for the current transaction.

The result of the matching is an updated manual posting in the external transaction. The account, code parts, text and the process code of the pseudo code are copied to the fields of the manual posting in the external transaction. However, the pseudo code is applied to the manual posting only if the transaction type is Direct Cash Payment.

The proposed action displays the load direct cash transaction after the payment matching is performed. The updated transaction is also instantly validated, e.g. if the account is valid for the statement date of the external payment, and any error is displayed in the error field of the transaction. The payment matching overwrites accounts, code parts, text, and process code each time the payment matching is performed. This also concerns manual posting.

The debit transactions mentioned at the beginning of this section are usually loaded with the transaction type Direct Cash Transaction. You can specify this transaction type also in the matching identifier in order to change the transaction type of the loaded transaction, if the payment is successfully matched with a pseudo code. E.g. the transaction is loaded with type Customer Payment and you want to change automatically to the type Direct Cash Transaction.

For identifying the relevant content in the matching reference, a label should be defined in the matching identifier. E.g. the label used can be INSURANCE NO. to extract the insurance number to be checked against pseudo codes directly after the label. In order to avoid mismatching transactions with pseudo codes that are randomly included in a matching reference, you should restrict the matching identifier to the relevant creditor by using the additional reference. This can be the name of the creditor (e.g. the name of the insurer) or another means of identification of the payment originator.

The strings for label and additional reference are case sensitive and are used as entered in the matching identifier when searching for the stings in the matching. The extracted string is verified against the pseudo codes, since the ID of the pseudo codes in the basic data of accounting rules are defined in uppercase.

If message codes are used for the payment format, the tax code defined in the message code is applied to the transaction when the external file is loaded.

Example of a debit transaction from an insurance company against the bank account:

The pseudo codes as defined:

The matching identifiers are defined as follows, in external payment parameters of company 92DE:

The external transaction after the matching: