Managing Direct Debiting according to the Danish Model
This document describes an alternative workflow for direct debiting payments that enables the payer to review and remove specific invoices from being paid by direct debiting before the company sends the bank remittance to the payment institution. Another feature is that the reconciliation of payments is made in the Automatic Bank Statements (ABS) module.
This workflow is based on a solution used in Denmark, where the payer approves direct debiting payments each time before the bank withdraws money from the payer's bank account.
See the M3 Localization Library (Cloud) and select
for configuration related to the electronic messages for remittance and confirmation.Outcome
Payments received in the ABS module are recorded and matched to the corresponding invoices. The customer credit and debt are updated. An accounting journal is printed.
Automatically processed payments improve the company's management of customer debts and risks.
Accounts receivable and the general ledger and their respective balance files are updated. The accounts receivable account is credited, and the bank account that was selected when creating the bank remittance is debited.
For remittance handled in 'Bank Remittance. Open' (ARS300), the status of the bank remittance in the bank remittance table, FARREM, is 11. The remittance status for each customer invoice in the table for bank remittance details, FARRED, is 9. The status of the bank statement is 9 in 'Bank Statement. Open' (ABS100).
For remittance handled in 'Remit Direct Debit and Factoring. Open' (ARS410), the status of the remittance in the remittance header table, FARRPH, is 95. The remittance status for each document in the detail table, FARRPD, is 9, and for each invoice in the invoice table, FARRPI, is 9. The status of the bank statement is 9 in 'Bank Statement. Open' (ABS100).
Before you start
Before you start, you must meet these prerequisites:
- The company must have an agreement with its payers to use this model for payment by direct debiting.
- A direct debiting agreement indicator must be defined with the 'Customer bank account' check box selected in 'Direct Debiting Agreement Indicator. Open' (ARS450).
- Setup of payment type
The payment type connected to the payment method that is used for the invoices to include in this workflow must have these check-box alternatives selected in 'Payment Type. Open' (CRS078):
- Electronic confirmation. Otherwise, you cannot download the electronic bank statement file with the receipts to the ABS module. For a description of this check box, see Create payment type.
- Agreement type. This indicates that the payments must be based on a valid direct debiting agreement in 'Direct Debiting Agreement. Open' (ARS450).
- For remittance in (ARS300): Alternative 1 (Manual printout of advice letter) in the 'Print advice' field. This alternative enables you to print a statement (ARS313PF) for a bank remittance to use as an advice letter before the bank remittance is confirmed. If this alternative is not selected, ARS313PF is only printed when the bank remittance is confirmed.
- For remittance in (ARS410): Alternative 1 (Manual printout of advice letter) in the 'Print advice' field. This alternative enables you to print the payment advice (ARS419PF) for all payers and document numbers in a remittance before the remittance is confirmed. If this alternative is not selected, a payment specification (ARS419PF) is only printed when the remittance is confirmed.
Note: If the check box 'Payment information' is selected in 'AR Payment Method. Open' (CRS076), the printout ARS419PF is controlled by the alternative selected for the field 'Print advice' in (CRS076).
- Process-specific ABS settings
- Set up the ABS module as described in Enabling Automatic Processing of Bank Statements. Below is a summary of the prerequisites specific to this process that either should or must be met in order for the system to receive and process bank statements in Denmark as described in this document.
See the M3 Localization Library (Cloud) and select
. - In 'Available Object Control Parameters. Open' (CMS016), the control object V1BKID ('Bank account') must be selected in field 1 and V3BLTT ('Transaction type') must be selected in field 2 for the program (ABS910). See below for the use of these control objects.
- Set up these settings in 'Bank Account Identifier. Open' (ABS900/E):
- A bank account that is registered with the appropriate currency in 'Bank Account. Open' (CRS692/E) must be selected.
- The field value &RECCD ('Record code', used as the transaction types mentioned below) should be selected in user-defined field 1 and &PAIN1 ('Rejected amount') in user-defined field 2. When including user-defined fields 1 (V2BLU1) and 2 (V2BLU2) in a user-defined view for (ABS101) in 'View. Open' (CRS020), the transaction type and the amount of payments rejected by the bank will then be displayed for each bank statement line in 'Bank Statement. Open Lines' (ABS101/B), thus making it easier to analyze variances between invoices and payments.
- Select the 'Enter bank statement manually' check box so that you can test the function before it is activated by manually specifying a bank statement and testing the automatic validation and allocation against a bank remittance.
- Set up the ABS module as described in Enabling Automatic Processing of Bank Statements. Below is a summary of the prerequisites specific to this process that either should or must be met in order for the system to receive and process bank statements in Denmark as described in this document.
- You mst create these transaction types in 'Transaction Type. Open' (ABS010): 0530 = Rejected (payments rejected by the bank), 0540 = Canceled (payment canceled by the bank for other reasons), 0555 = Reversed (payments that has been canceled by the payer after the direct debiting statement was remitted to the bank), 0580 = Processed payments (credit transactions), and 0585 = Processed payments (debit transactions). The corresponding transaction type is displayed for each bank statement line in 'Bank Statement. Open Lines' (ABS101).
- At least two accounts receivable scenarios, one for payments processed by the bank and one for rejected payments, with scenario type 6 must be defined in 'Scenario Number. Open' (ABS911). This scenario type, which is reserved for the process described in this document, searches for invoices that match receipts in a bank statement in the tables for bank remittance in (ARS300), FARRED, and FARREM, or in (ARS410), FARRPI, FARRPD and FARRPH. The 'Completed' check box on (ABS911/E) defines whether the scenario is applied to payments processed by the bank or payments rejected by the bank. Bank statement lines that are linked to a scenario with the 'Completed' check box cleared are not included in the automatic allocation of invoices to bank statement lines in the ABS module.
- The scenario must be connected to a combination of values for control objects 'bank account' (V1BKID) and 'transaction type' (V3BLTT) in 'Scenario Number. Prioritize' (ABS910).
See Prioritize Scenarios for Allocating Invoices to Bank Statements Lines on the use of control objects.
For example, if you select a scenario with scenario type 6 and with the 'Completed' check box cleared for a specific bank account and transaction type 0530 (Rejected) on (ABS910/E), a bank statement line with this bank account and transaction type 0530 in the Infor Enterprise Collaborator message is classified and displayed automatically as a rejected payment in the bank statement. No invoices can be allocated to such a line.
Follow these steps
- Register direct debiting agreement
The first time this process is applied to a payer, register the direct debiting agreement in 'Direct Debiting Agreement. Open' (ARS450). The indicator connected to the agreement enables the company to include any country-specific values, such as a social security number. Depending on the M3 Business Engine version you have, you can create a direct debiting agreement without specifying a customer bank account.
Send the direct debiting agreement to the payment institution. Do this manually as a printed document or as an electronic file.
- Notify payer of future withdrawal
On a periodic basis, create a bank remittance proposal in 'Bank Remittance. Open' (ARS300) for payments by direct debiting as described in Create Invoice Remittance for Direct Debiting/Factoring or 'Remit Direct Debit and Factoring. Open’ (ARS410) as described in Create remittance for direct debiting or factoring in (ARS410).
Before you confirm the bank remittance:- For (ARS300): Select option 11 = 'Print advice' to print a direct debiting statement (ARS313PF) to use as an advice letter.
- For (ARS410): Select option 6 = 'Print payment advice' to print a payment advice (ARS419PF to use as an advice letter.
Send the advice letter to the payer, who decides whether to exclude any invoices from being paid by direct debiting. The payer can also add invoices to the bank remittance.
In Denmark, the payer usually has up to seven days to decide before returning the advice letter with the requested changes.
- Make changes requested by payer
Remove any invoices for which the payer has not approved payment by direct debiting from the bank remittance proposal, or add invoices to the proposal in (ARS300) or in (ARS410) as described in Adjust remittance for direct debiting or factoring in (ARS410).
If applicable, change the payment method for the invoices affected in 'Customer Invoice. Change' (ARS201), which is accessed from 'Accounts Receivable. Display' (ARS200), to prevent the invoices from being included in another bank remittance for this type of direct debiting payment.
- Remit invoices to payment institute
Confirm the remittance by selecting option 9 = 'Confirm' in (ARS300) or (ARS410). Because the 'Electronic confirmation' check box is selected for the payment type of the included invoices, the system creates an electronic file using Infor Enterprise Collaborator. The remittance is then assigned status 11 in (ARS350) or status 95 in (ARS410). This status means that payments based on the remittance can only be reconciled in the ABS module. The individual invoices are assigned remittance status 0 in the detail table FARRED for (ARS300), or status 8 in the detail and invoice tables FARRPD and FARRPI for (ARS410). The combination of statuses,11 and 0 for (ARS300), and 95 and 8 for (ARS410), enables M3 to identify which remittances and invoices to include in the automatic allocation in the ABS module.
No account entries are created when confirming the bank remittance and the invoices included in the bank remittance are still open. However, the invoices are assigned block code 9 in the field 'Payment reminder stop' in 'Customer Invoice. Change' (ARS201) to prevent them from being included in another bank remittance.
Send the file to the payment institution that will process the payments. The payment institution transfers payments from the payer's bank account to the creditor's bank account on the due date.
An internal remittance report, ARS311PF for (ARS300) and ARS414PF for (ARS410), is printed when you confirm the remittance proposal. The report can be used later to facilitate any manual reconciliation of payments.
- Receive bank statement file with receipts
After the payments are made, the payment institution returns a bank statement file with confirmation of the receipts. The file is received in Infor Enterprise Collaborator and downloaded into the ABS module by means of API program ABS100MI.
One receipt, corresponding to one bank statement line, can refer to several invoices such as one receipt for each payment date in the bank remittance. The file can also include receipts from previous bank remittances. In other words, the bank statement does not necessarily correspond to one specific bank remittance exclusively. In Denmark, the file contains information about the payer, payment date, payment amount, and currency, but not the actual invoice numbers. The lack of invoice numbers makes this process different from the regular workflow in the ABS module, where the allocation to invoices often is based on invoice numbers.
The received bank statement is displayed in 'Bank Statement. Open' (ABS100). The bank statement lines displayed in 'Bank Statement. Open Lines' (ABS101) reveals the transaction code, for example, 0585 for a payment processed by the bank or 0530 for a rejected payment. Bank statement lines for rejected payments display the rejected amount but no invoices can be allocated to such a line in the automated allocation described below.
- Validate bank statement
Trigger the automated validation of receipt data in the bank statement in (ABS100), as described in Initiate Automatic Validation of a Bank Statement and Correct Any Errors. The bank statement receives status 3 if errors were detected. Examples of errors are that the currency is not registered or that the bank account is invalid. Select option 12 = 'Errors' to display the error descriptions in 'Bank Statement. Display Error' (ABS103). Make the required corrections. If no errors were detected during the validation, the bank statement receives status 4 (Ready for allocation).
The validation and the subsequent allocation of receipts can be completely automated, depending on how the ABS module is set up.
- Automatically reconcile payments
Trigger the automated allocation of invoices in accounts receivable to receipts in the bank statement in (ABS100), as described in Initiate Automatic Allocation of a Bank Statement. M3 allocates invoices to the corresponding bank statement lines based on the combination of payer and payment date in the bank remittance table, FARRED for (ARS300) or remittance invoice, FARRPI, for (ARS410). Since a single receipt (bank statement line) can refer to several invoices, there is no automatic verification of the receipt amount against the invoice amounts. Thus, the total of the receipts in the bank statement can be higher or lower than the total amount of the invoices selected in the allocation.
If the total invoice amount per payer and payment date matches the total paid amount in the bank statement, all bank statement lines are assigned status 6 (Completely allocated) in 'Bank Statement. Open Lines' (ABS101). If the amount does not match, the bank statement line receives status 5 (Partly allocated) and has to be adjusted manually in (ABS101).
A preliminary voucher is created during the allocation, but the general ledger cannot be updated until all receipts are allocated.
- Manually manage variances
Any remaining variances must be managed manually. See Allocate a Bank Statement Line Manually. You can identify the invoices included in a specific bank remittance in these ways:
- Use the internal remittance report, ARS311PF or ARS414PF, which is created in (ARS300) or (ARS410).
- Open (ARS300) by selecting option 20 = 'Bank remittance' for a bank statement line in (ABS101) or (ABS102). From (ARS300) you can drill down to the individual invoices or open (ARS410) to drill down to the documents or invoices.
- Select additional information number 210 in 'Accounts Receivable. Display Additional Info' (ARS250) and then specify the bank remittance number.
Managing over-allocation
If the total amount of the remitted invoices per payer and payment date is higher than the corresponding amount of the bank statement line, too many invoices were allocated to the bank statement line in the automatic allocation. Since the bank statement file did not contain any invoice numbers, you will have to establish on your own the reasons for the over-allocation as well as identify which invoices do not belong to the respective bank statement line. You can redistribute the allocation manually by removing invoices from a particular bank statement line and add it to another line in (ABS102).
However, the most likely reason for over-allocation is that the payment institute could not process the payment due to insufficient funding of a payer or that the payment institute has rejected the direct debiting payment. Because no invoices can be allocated to bank statement lines with a transaction code for rejected payments, they are automatically allocated to other matching bank statement lines instead. Solve the problem by removing invoices allocated to the bank statement line in 'Bank Statement. Open Line Details' (ABS102) and then remove the block code for the invoice in 'Customer Invoice. Change' (ARS201) for invoices remitted through (ARS300). For invoices remitted through (ARS410), use option 25-'Release direct debiting' in 'Acc Receivable. Display' (ARS200) or in 'Customer Invoice. Display in Number Seq' (ARS205). The invoice can now be included in a new remittance to the bank.
How to proceed after that depends on the company's policy for customer debt management. For example, after contacting the customer, you might change the payment method or the due date of the invoice, or decide to charge penalty interest.
If the payment is eventually received in another way than through the direct debiting routine, you record the payment and allocate it to an invoice manually in 'Payment Received. Record' (ARS110). In this case, you will receive a warning message that the invoice is included in a bank remittance. You can proceed without taking action on the message.
Managing under-allocation
If the total amount of the remitted invoices per payer and payment date is lower than the corresponding amount in the bank statement, not enough invoices were allocated. Solve the problem by selecting one or both of these alternatives:
- Create an on-account payment for the payer on 'Payment Received. Record' (ARS110/F), a program accessed from the bank statement line by selecting option 7 = 'AR payment' in (ABS101) or (ABS102). See Record Customer Payment on Account. The on-account payment must match the corresponding invoices later in (ARS110).
- Manually allocate one or more invoices in (ARS110/F) to the bank statement line, using the 'AR payment' option in (ABS102).
- Update ledgers
End by selecting option 9 = 'Update GL' for the bank remittance in (ABS100) to create the voucher and update accounts receivable and the general ledger.