The purpose of the External Interface for Payments is to create payments from electronic payment files. The interface allows you to process external files of various formats and payment institutes. The process includes loading and validating the external file, automatic matching of the payment, and transferring to a mixed payment for the approval and posting of the payment.
The external payments interface functionality is used in the processes of Customer Payments on File, External Supplier Payment on File and External Mixed Payment on File. The interface includes predefined payment formats for different purposes:
Each payment format is connected to an external file template that defines the file structure and the data to be imported from the file. You can view the available formats and its file templates in the payment formats definition. The payment format and external file template are defined at installation time of the system.
The interface includes a set of parameters in the External Payment Parameters window which are required for all types for payment files. The parameters are defined per payment method and gives you the flexibility to define individual set ups for different payment files, bank accounts etc.
When you load the external file, the payment type code for the external payment and the initial transaction type for the single payment transaction is determined by the payment format and its connected external file template. The payment type code is used to control which transaction types are allowed in an external payment.
The possible Payment Types are:
The possible Transaction Types are:
Note: Mixed Payments loaded from file, do not include transactions to acknowledge supplier payment orders, direct debiting orders, or customer repayment orders.
The Transaction Types that can only be entered and matched manually in external payments client:
The Proposed Action informs about the intended payment and what will be included in the transfer to mixed payment. The displayed action is a suggestion which depends on the transaction type and the payment matching result. Possible proposed actions are:
You can create multi-company payments by matching the payment with invoices of another company and by creating unmatched payments against another company. This includes new customer difference items, too. A multi-company payment is created also for direct cash transactions which includes a manual posting against another company.
The matching function can be used to include invoices of another company automatically, based on the specified matching identifiers. For direct cash payments, pseudo codes can be used in the payment matching to complete a direct cash transaction automatically with a manual posting against another company. You define in the matching identifiers the companies, of which the invoices and pseudo code should considered for the payment matching. Note: Matching Identifier can be used only for specific payment formats.
Some of the information of the external payment file are transferred to the mixed payment with its original values. You can use this information, e.g., to complete the matching manually in mixed payment or for other information purposes. The original data comprise of:
The original file info and the bank transaction info are displayed as loaded from the external payment file since both are not editable in external payments. The payment currency and payment amount of the external transaction can be modified in external payments and can be helpful in mixed payment, if the payment amount/payment currency is refreshed due to change in the matching of invoices. The original data are displayed in mixed payment transactions and in the matching dialog.
When a mixed payment using an external payment is created, the external payment and its transactions are connected to the final mixed payment. This connection supports you to trace the final result of an external payment.
You can open the attached mixed payment by using the context menu in external payments. Depending on your selection in external payments on the header or on the detail line, the single mixed payment is displayed or several mixed payments are listed. The mixed payments analysis shows also the load id of the external payment from which it was created. You can also open the external payment from the mixed payment analysis.
The external file template of the payment format REMADV (template CUP_REMADV) is a generic file template for the EDI message type REMADV which uses common EDI segments but is not designed to cover all EDI subsets. The generic file template can be used for EDI subset EANCOM. You can copy the existing payment format to amend your new file layout to the requirements of your EDI subset. The import of an EDI remittance advice REMADV requires in the file records that are delimited with Carriage Return/Line Feed (CR/LF). Each EDI Segment must be delimited with CR/LF in order to load the EDI Segments as individual records. The single quotation mark (') in the external text file, which is the EDI Segment Terminator, must be converted to circumflex (^) before loading the file into the external payments interface.
The external file template of the payment format DEDUCTION (template CUP_DEDUCTION) is a generic file template used for the purpose of creating payments from a payer's remittance advice file. The file layout is normally used as a template for payer specific file layouts. You can copy the existing payment format and amend the new file layout.
Before you load the external file from your bank, or from another institution, you are required to define the external payment parameters per payment method. This is necessary for all possible types of external payments because the parameters define how the external file should be loaded, the method how the payments from the file should be matched, and how the external payment should be transferred to a mixed payment (s). When you load the external file, the selected payment method will be connected to the external payment. The parameters defined for this method will be used in each step in the process.
The external payment parameters includes these parameters per payment method:
Note: The company identifier of the external payment parameter is defined per payment format and can be entered in external payment parameters for payment methods of the same payment format.
The advantage of external payment parameters per payment method is that you can set up the parameters most suitable for the bank file or remittance information on the file. You can also define for the same payment format several payment methods, if for the same type of payment file, different set ups are required.
E.g. if you process different types of payment files in your company, the matching identifiers per payment method will help to optimize the matching result since the information to be used for the matching depends on the content of the file, that is loaded by using the payment method. Another example of several set ups could be, if in one of your cash accounts mainly customer payments are received whereas in another cash account payments are credited which are not customer payments. For payment formats with message codes, which is a code in the bank file to identify the type transaction, you can set up in this situation the transaction type Customer Payment and Direct Cash Transaction individually per payment method. When you load the file, select the relevant payment method for the cash account and depending on the message code set up in the payment method, you will create customer payments or direct cash transaction for the same message code.
The following overview shows for each activity of the import payment transaction process the respective parameters, which are used depending on the payment format. Click on the linked parameter descriptions to read more about the single parameter:
| Activity | Relevant External Payment Parameters |
| Load External Interface | Message Codes Reason Codes Deduction Rules Matching Options: Allow Automatic Matching Company Identifier |
| Check External Payment | N/A |
| Match and Check Items | Message Codes Matching Options Matching Identifier Write-off |
| Create Mixed Payment | Segmentation Criteria |
The message codes of external payment parameters are differently used in the external payment interface and are displayed in the external payment transaction.
Message Codes are available in external payments for payment formats with a file template that is used to identify the type of transaction in the file. E.g. the codes of the MT940 swift formats (MT940NLABN, MT940DE) can be found in the message codes. You can change such message code to control the transaction loaded form the external file according to your requirement. You can select the transaction type that mostly apply to the code specified in the bank file and set up other parameters of the message code which should be applied when transaction is loaded.
For direct cash payments, you can define the tax code, account or even a pseudo code to be used for the manual posting. The account, code parts, process code and text of the pseudo code are copied to the manual posting which can include e.g. a cost center. Examples for this are transactions of bank fee, cash concentration and other similar transactions for which the message code clearly indicates what should be included in the manual posting. Another intention could be to define a default account or pseudo code, that can overridden with the result of the payment matching by using matching identifiers for the payment.
You can select for customer payments if a new item should be created. For the new item, the tax code, new item invoice type, new item invoice series, payment terms and difference code are used for the loaded transactions. More details about new items can be found in the topic New Customer Difference Items out of External Transactions.
The transaction type for cashing issued checks can be pre-selected for transactions to cash supplier checks and to cash customer repayment checks.
You can connect matching identifiers to the message code. By this you can control what should be matched with the payment, loaded with the message code. This helps to avoid to mismatch the payment and can speed up the automatic payment matching.
Note: Any change of the transaction type and other parameters of the message code for payment formats that are used to to acknowledge direct debiting orders or supplier payment orders should not be modified to ensure the correct handling of the automatic payments. Such message codes should be kept as created by the system.
Other payment formats, such as DDNAGSEK or DDBGSEK, use the message code to notify you about errors, identified by your bank and reported in the loaded file. Normally, the set up of such codes should be used as created from the payment format. Transactions, loaded with message codes to notify errors, can be displayed in the External Payments Error Log window.
Note: The message code for payment formats that are used to to acknowledge direct debiting orders or supplier payment orders should be kept as created from the payment format to ensure the correct handling of the automatic payments.
For payment formats without message code, the initial transaction type which is defined in the external file template is used when the transaction is loaded from the file.
The reason codes are connected to message codes and categorizes additional detailed information about the transaction. The reason code are loaded from the external file together with the message code, if both are available in the external file and considered in the external file template. You can set up in the detail section of predefined reason codes the difference code to be applied for a new customer difference items, which should be created based on the message code from the file. More details about reason codes and other relevant parameters for new items can be found at New Customer Difference Items out of External Transactions.
The external payment parameters includes general matching options for the payment method. These options are applied to external payments that are loaded from the file or entered manually with the payment method. However, for payment files to acknowledge supplier payment orders or direct debiting orders, these options are disregarded.
You can select the Allow Automatic Matching check box if the external payments should be matched automatically when the file is imported. If the payments are not matched, you can match the payments at a later time by using the separate function Match and Check Items and also by entering the customer invoice etc. manually. This check box is relevant for payment files for which the matching identifiers are used.
There are options to control payments that do not match due to the amounts. You can select the Consider Customer/Company Tolerances when Matching option, if remaining amounts within the tolerance, defined in the customer and/or company, should be automatically handled, i.e. the difference between payment amount and the amount of matched invoices is written off with the tolerance write-off code. Additionally, you can select the Only Complete Matching of Payment Amount check box, for payments matched with customer invoices only, if the payment amount from the file matches the expected payment amount for the invoice(s) based on the open amount, available discount, deductions and write-off within the tolerance.
For payment file with message codes, you can restrict the matching identifiers to be applied in the payment matching. When the Only Identifiers connected to Message Code check box is selected, only the matching identifiers specified for message code are used in the payment matching.
The matching identifiers are used in the external interface for payments to search for invoices and/or issued checks, and to match the payment with the ledger items found. If an invoice is matched, the open installment is included in the matching details and if there are several open installments, then the installments are matched in ascending discount order or by due date. You can also use the matching identifiers for direct cash payments in order to complete direct cash transactions automatically with a manual posting.
The matching identifiers are used by the payment matching independent of the transaction type that is loaded from the file, or specified in the message code. However, for the payment files to confirm payment orders or which include a direct reference to the invoices, the matching will not be performed. The direct reference to an invoice is used e.g. for the OCR payment files of the Nordic market and the Swiss ISR customer payments. The transactions to create a new customer difference item are excluded from the payment matching too.
You define the matching identifiers in the Definition of Identifiers tab of the External Payments Parameters window per payment method.
You can also connect matching identifiers to the message code in order to restrict the identifiers being used in the payment matching. E.g. the message code 001 of MT940DE format indicated in the bank file means that a check is cashed. In such an instance you can select the relevant matching identifier to search for the issued checks connected to 001. The Only identifiers Connected to Message Code check box should be selected to use this particular identifier type. All message codes with identifiers for which the payment matching should be done must be connected first If a specified identifier is to be used for a given message code. By connecting identifiers and message codes you can control what should be matched with the payment. This will help avoiding mismatching of payments and speed up the automatic payment matching.
The matching identifier consists of parameters to control the type of data that should be extracted from the file and the type of information in IFS/Financials that should be matched with payments.
The data extract can be specified for these parameters:
The parameters, to determine which information should be matched with the payment, are:
You can find more details and examples relating to this in Matching Identifiers for External Payments.
Apart from using automatic matching for matching identifier you can manually match customer invoices, supplier checks and customer repayment checks. Also the pseudo code can be entered directly in the manual posting of external payment. The account, code parts, text and process code of the pseudo code is copied into the manual posting.
Supplier Invoices can only be matched manually.
The deductions and discounts are automatically calculated when matching the payment with invoice(s). You can view the calculated results in the matching details of each transaction in the external payments.
The discount for the invoice/installment is calculated based on the transaction date of the payment detail line considering tolerance days which can be specified for the customer and/or company. However, if the external payment file acknowledges the supplier payment order or a direct debiting order, the discount of the order item is directly applied to the payment since the discount will be applicable in the outgoing payment file.
The deduction amounts are calculated according to the deduction rules of the deduction group that is specified on the invoice, at the time when the payment is created in IFS/Financials, however, deductions are not considered in payments from direct debiting orders.
It is also possible to load the deductions and/or the discount amount from the external payment file. You can view the amounts loaded from the file for each transaction in the external payments. The calculated deductions and the calculated cash discount amount are displayed and allows you to check the transactions for possible deviations. The deductions and/or the cash discount amount from the file are used for payments even though the matched invoice were originally created without deduction and/or discount.
When the deductions from the file is used, you are required to set up the deduction rules in the external payment parameter for the payment method, that is used for loading the external file. Each deduction line amount in the file must be connected to the relevant deduction rule of the deduction group by using the deduction identifier. The deduction identifier is the label for the deduction amount in the external file and/or in the external file template.
Following is an example of setting up deduction rules in external payment parameters:
| Deduction Identifier | Deduction Rule | Deduction |
| 38 | BON20 | Bonus, 2 % from Invoice Gross Amount |
| 15E | DELC15 | Delcredere provision, 1.5 % from Invoice Gross Amount |
More details can be found in Deductions and Discount from External Payment File.
For customer payments, you can handle differences between the lump sum payment amount and the payment amount applied to the invoice installment(s) automatically. You can define the write-off parameters in the external payment parameters per payment method which allows you to apply tolerances, e.g. different tolerances for payment files, bank account, or when you receive a payment advice on file from your customer.
You can define the tolerance as the exact amount meaning the remaining amount of the payment transaction must be exactly equal to a particular amount in order to write off the amount e.g. to write off overpayments due to paid reminder fees which were just printed in the reminder earlier. Also tolerance amount and tolerance percentage are separately available to define different limits for overpayment and underpayment.
The write off defined in the Write-Off Parameters tab, for exact amount and tolerance for overpayment/underpayment are posted by using a new customer difference item that is immediately written off. The new customer difference item is used for this purpose, irrespective if one or several invoices or invoice installments are matched with the payment transaction. The new item is instantly added to the matching details when the payment matching is finished for the transaction.
The tolerances specified in the customer and/or company are also used, if in the external payment parameters the general matching option Consider Customer/Company Tolerances when Matching is selected. This write-off is handled directly on the invoice installment.
When the payment is automatically matched or manually matched with customer invoices, the payment is checked for possible write-off in this order:
For all tolerances defined in the write-off tab you can specify individually the write-off code, invoice type, invoices series and tax code, that are used for the new customer difference item.
Different write-off codes allows you to post the write-off on different accounts, depending on set up of the posting control of posting types PP17 and PP34. In this way you can also control which of the write-offs are costs or revenues.
The new customer difference item is created with the specific invoice type and invoice series. In the follow-up analysis of the customer's ledger items you can directly see which overpayment and underpayment were caused by the customer's payments.
The tax code can be specified for each tolerance, but can be empty also and then the tax code of the customer is applied to the new customer difference item. Tax reductions are posted according to the setup of the write-off code. If the write-off code is taxable, the tax posting is created according to the tax code specified in the write-off code.
The exact tolerance amount can be used to handle differences, e.g. paid reminder fees which can be included in the payment amount. Bank charges, deducted from the original payment by the payment institute, can also be a dedicated amount which causes a difference between the lump sum payment amount and the matched invoices.
The tolerance parameters are set up for a specific payment currency and amount. A positive value in the exact amount is the exact tolerance amount to be used for an overpayment, a negative value is the exact tolerance amount to be used for an underpayment. Additionally you can connect the tolerance to a certain reminder template and reminder level for the purpose of identifying the overpaid amount as a paid reminder fee.
An overpaid or underpaid amount is written off if the information of the payment matching listed below applies to the criteria specified in the exact amount parameters:
If the payment is matched with several invoices, the invoice with the highest reminder level determines the reminder level, reminder template and company to be checked against the tolerance parameters. You can define exact amount parameters without reminder level and reminder template. Such tolerance parameters are applied to payments matched with invoices of any reminder level.
The new customer difference item to write-off the payment difference is created in the company to which the matched invoice belong. If several invoices are included in the matching, the invoice with the highest reminder level determines the company for which the new item is created. The write-off parameter allows you to define the write-off code, invoice type and invoice series for each exact amount tolerance individually.
Note: The write-off is based only on the information in the payment matching. It does not checked, which reminder fee was printed in the reminder.
The tolerance for overpayment and underpayment can be defined with amount limits and as percentages. These tolerance is applied to the payment if the difference between the payment lump sum amount and the matched invoices is within the limit. If you have defined a percentage, the amount limit, up to which the difference is automatically written off, is calculated with this percentage based on the invoice amounts of the matched invoice installments. If a tolerance amount and tolerance percentage is specified, the lower amount of both is used to check the remaining payment amount.
The new customer difference item to write-off the differences is created for the company, to which the matched invoice belongs. If several companies are involved, the write-off will be in the payment company. The write-off parameter allows you to define the write-off code, invoice type and invoice series for each affected company individually. The new item for the write-off is only created for companies, for which the write-off information are defined.
The segmentation criteria of external payment parameters allows you to create several mixed payments out of one single external payment's load ID. The segmentation criteria can be a helpful functionality, if you need to deal with large volumes of incoming payments. Incoming payments, especially with unstructured reference, can require some extra work, e.g. to complete the payment matching manually. After the external payment is split into mixed payments, several users can work on the incoming payments since each user works on his/her single mixed payment. As soon as a user has completed the mixed payment, he/she can approve the mixed payment independently of the other mixed payments. For external payment transactions, for which no manual work is needed, you can select if the mixed payment should be automatically approved using a background job. Another example of using segmentation criteria could be if the external payment should be split up in customer payment, supplier related payments (e.g. checks) and direct cash transactions since the payments are reviewed by different accounting departments.
You can split the external payment, when it is transferred to mixed payment, according to these criteria:
When you create the mixed payment from the external payment, the external transactions which meets the criteria defined in a segmentation row, are included in the individual mixed payment. You can limit the number of transactions to be included in one mixed payment. E.g. if you want to create a separate mixed payment for the proposed action Load Payment On Account, the mixed payment can be limited based on the number of unmatched payments included in a mixed payment. When the limit is reached, a new mixed payment will be created and several users can manually complete the matching of the different mixed payments, if necessary. A similar example would be, if you receive payments from a large customer for whom you need to check for complete matching against a payment advice. You can collect the transactions of the payer into a mixed payment by using the payer ID and/or the bank transaction information fields as segmentation criteria.
For each row of segmentation criteria you can define the statement number format which is used for the statement number of the mixed payments, that are created by using the row of segmentation criteria. The statement number format can include a text constant and/or the statement date. The text constant can indicate what is in the mixed payment you have created, e.g. if the criterion is transaction type Customer Payment, you could use as constant CUST. The statement numbers of the mixed payments created includes in the beginning word CUST. The statement date of the external payment can be also included in the statement number of the mixed payment. For this, you need to enter the substitution variable for date (YYMMDD or DDMMYY) to give a correct format.
Example:
The constant and the date substitution variable for formatting the statement number can be in any order, e.g. YYMMDD-CUST is also possible. If the statement number format is empty, the statement number will be automatically generated based on the statement number of the previous mixed payment, created for the cash account.
Note: If the statement number prefix is specified in the cash account data, the prefix will not be used if the mixed payments are created by using the segmentation criteria.
For all items of a load ID that are remaining after processing all steps in the segmentation, the statement number will be the statement date of the external payment, in date format YYMMDD.
Note: When you specify the segmentation criteria, you need to select the Use Step No check box, if the segmentation row should be considered when you create the mixed payment. If you load the external payment into an existing mixed payment, the segmentation criteria are omitted and all transactions are added to the selected mixed payment.
After you have created the mixed payment(s) you can see for each external transaction the statement number, that informs in which mixed payment the external transaction is included. The cash account of the mixed payment is displayed also in the header information of the external payment. It is also indicated on the detail line, which segmentation rule included the transaction and if you have grouped the transferred transactions by customer/supplier. You can open the attached mixed payments for the detail transaction or for the whole load ID in order to trace the final results of external payments.
The opening balance and closing balance of the mixed payments you have created by using segmentation criteria is recalculated. I.e. the opening balance for the single mixed payment is zero, and the closing balance is the total of all debit and credit transactions included in the single mixed payment.
External Payment Transactions in the External Payments per Load ID window, statement date 2013-03-30:
| Transaction Type | Proposed Action | Payer/Payee | Payment Amount |
| Customer Payment | Load Invoice | 1020 | 12000 |
| Customer Payment | Load Invoice | 1020 | 1000 |
| Customer Payment | Load Invoice | 1030 | 2000 |
| Customer Payment | Load Payment On Account | 1030 | 2000 |
| Cash Issued Check | Load Supplier Check | 4000 | -8000 |
| Direct Cash Transaction | Load Direct Cash Transaction | 2500 |
Segmentation Criteria in the External Payments Parameters window:
| Step No | Description | Transaction Type | Proposed Action | Bank Transaction Info 1 | Payer/Payee | Statement No Format |
| 1 | Payments of Customer 1020, matched fully with invoices | Customer Payment | Load Invoice | % | 1020 | CUST1020-YYMMDD |
| 2 | Matched Customer Payments | Customer Payment | Load Invoice | % | % | CUST-YYMMDD |
| 3 | Unmatched Customer Payments | Customer Payment | Load Payment On Account | % | % | UNMATCHED-YYMMDD |
| 4 | Other payments | % | % | % | % | OTHER-YYMMDD |
Results in Mixed Payments:
First Mixed Payment with Statement Number CUST1020-20130330:
| Transaction Type | Payer/Payee | Payment Amount |
| Enter Customer Payment | 1020 | 12000 |
| Enter Customer Payment | 1020 | 1000 |
Second Mixed Payment with Statement Number CUST-20130330:
| Transaction Type | Payer/Payee | Payment Amount |
| Enter Customer Payment | 1030 | 2000 |
Third Mixed Payment with Statement Number UNMATCHED-20130330:
| Transaction Type | Payer/Payee | Payment Amount |
| Enter Customer Payment | 1030 | 2000 |
Forth Mixed Payment with Statement Number OTHER-20130330:
| Transaction Type | Payer/Payee | Payment Amount |
| Cash Supplier Check | 4000 | -8000 |
| Direct Cash Payment | 2500 |
The payment file received from the bank may include e.g. bank statements of different accounts connected to different companies. The idea of the company identifier is to recognize automatically the company to which the payment transaction belong in the file and to load the transactions from file in the relevant company. By using company identifiers, you can create several load IDs in different companies although you load one single file. The company identifier that is used for the individual load ID, is displayed in the external payment.
You can set up the company identifiers in the external payment parameters. These identifiers are character strings that are checked when loading the file. If the identifier is included in the file, the company payment institute and payment method of the company identifier are used when the external payment's load id is created. The company identifier is optional and if not specified, the payment file is loaded in the company for the payment institute and payment method, you have entered in the load file dialog. Although the external payment parameters are defined per payment method, the company identifiers of all payment methods, that belong to the same payment format of the current method, are editable.
Since the payment institute and the payment method is defined per company identifier, you can also create external payments for different banks from one file. The payment method in the identifier allows you to control which parameters should be applied for the individual external payment, e.g. if specific manual postings for the bank account should be created according to the message code, or whether another set of matching identifiers should be applied to the payments.
The character string of a company identifier depends on the structure and content of the payment file. Currently, the company identifiers are only used for the payment format MT940DE (MT940 Germany).
This payment format combines bank code and account number from the file as the company identifier.
| Example of the payment file | ||
| Statement in file | File lines | Value in column COMPANY_IDENTIFIER |
| #1 | :20:DEUTDEFFXXX |
79070016/02344760000 |
| #2 | :20:STARTUMSDIRECT DEBIT AUTHOR?109248?2072311196?21723111 |
DEUTDEMM792/DE46790700160234432000 |
Example of company identifiers, base on the file example above:
| Company Identifier | Company | Payment Institute | Payment Method | Method belong to Payment Format |
79070016/02344760000 |
DE01 | DB | MT940D | MT940DE |
DEUTDEMM792/DE46790700160234432000 |
DE02 | DB | BKSTMT | MT940DE |
The statement #1 is loaded in external payments of company DE01 and the payment institute DB and payment method MT940D are used as the load parameters for the bank statement. The statement #2 is loaded in the company DE02 with the parameters payment institute DB and payment method BKSTMT. Note: The payment method BKSTMT is of the same payment format MT904DE like the first company identifier.
The value of the company identifier can be displayed in the External File Transactions window if the external file template of the payment format includes the COMPANY_IDENTIFIER column. The column is currently available only for the MT940DE payment format. Search for rows with header records (i.e. 0_START and 1_HEAD record types) in the External File Transactions window. If you select one of the lines, the COMPANY_IDENTIFIER column will be displayed at the bottom of the window with the content of the loaded file.