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. The payments are processed by an intermediate Danish company Payment Business Service (PBS), owned by the Danish banks.


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.

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).

Before you start

Follow these steps

  1. 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 entering a customer bank account.

    Send the direct debiting agreement to the payment institution. The payment institution is the bank or, in the case of Denmark, PBS. Do this manually as a printed document or as an electronic file. For details, see Managing Direct Debiting Agreements.

  2. 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.

    Before you confirm the bank remittance, select option 11 = 'Print advice' to print a direct debiting statement (ARS313PF) to use as an advice letter. Send the advice letter to the payer, who will decide whether to exclude any invoices from being paid by direct debiting. The payer might also want to add invoices to the bank remittance.

    In Denmark, where the advice letter is sent to the payer through PBS, the payer usually has up to seven days to decide before returning the advice letter with the requested changes.

  3. 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 'Bank Remittance. Enter Details' (ARS310), a subprogram of (ARS300).

    To help identify the invoices, use the information views in (ARS310/B) to display either all invoices per payer (view 1) or the total of all invoices per payer and payment date (view 3). View 3 enables you to remove, hold, or release all invoices for a combination of payer and payment date within the proposal with one mouse-click. To switch between the two information views, use option 11 = 'Zoom'.

    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.

  4. Remit Invoices to Payment Institute

    Confirm the bank remittance by selecting option 9 = 'Confirm'. Since the 'Electronic confirmation' check box was selected for the payment type of the invoices included, an electronic file is created by means of Infor Enterprise Collaborator and the bank remittance is assigned status 11 (Reconciled) in the bank remittance table, FARREM, as displayed in 'Bank Remittance. Reconcile Payment' (ARS350). This status indicates that payments based on the bank remittance can only be reconciled in the ABS module instead of in (ARS350). The individual invoices are assigned remittance status 0 in the table for bank remittance details, FARRED. The combination of these two statuses, 11 and 0, enables M3 to identify which bank remittance and which invoices to include in the automatic reconciliation.

    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 '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 will transfer payments from the payer's bank account to the creditor's bank account on the due date.

    An internal bank remittance report, ARS311PF, is printed when you confirm the bank remittance. This report, which is sorted per payment date and payer, can be used later to facilitate any manual reconciliation of payments.

  5. 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 to 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.

  6. 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.

  7. 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. 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 will have 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.

  8. Manually Manage Variances

    Any remaining variances must be managed manually. For details, see Allocate a Bank Statement Line Manually. You can identify the invoices included in a specific bank remittance in the following ways:

    • Use the bank remittance report, ARS311PF, which was created in (ARS300).
    • 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.
    • 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. It is possible to 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. Since 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 removing the block code for the invoice in 'Customer Invoice. Change' (ARS201) so that the invoices can be included in another bank remittance.

    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; simply ignore 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 the following alternatives:

    • Create an on account payment for the payer in 'Payment Received. Record' (ARS110/F), a program accessed from the bank statement line by selecting option 7 = 'AR payment' in (ABS101) or (ABS102). For details see Record Customer Payment on Account. The on account payment will have to be matched to 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).
  9. 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.

Related topics