Using Payment Proposals to Create Supplier Payments

Factors for selecting invoices

• Selection criteria for the proposal

  The basis for the proposal is the selection criteria you specify in 'Supplier Payment Proposal. Create' (APS131/E). You can define up to eleven such criteria – the more you define, the more you narrow down the selection:

  Field	The field indicates...
  Payment type	… a range of payment types to which the supplier invoices belong. The payment type is a general classification of payments, to which several payment methods can be connected. The payment type itself is not manually specified but is connected to the invoice using the payment method selected.
  Payment method	… the payment method of the supplier invoice. The payment method is a subcategory of a payment type. It contains additional values that control how the payment is processed. Particularly important in this case is the 'Grouped payment' code – see below.
  Due date	... the due date range that selects invoices to be included. Note: Invoices containing a cash discount date that falls within the date range is always selected, provided that the cash discount date is today's date or later. Credit invoices in AP are always selected, regardless of due date. If the due date is later than the selected range, the invoice is assigned block code 4 in the proposal.
  Invoice date	... a range of dates from which the invoices are valid.
  Supplier group	... a range of different categories of suppliers. These supplier groups are created in 'Supplier Group. Open' (CRS150). Each supplier is then connected to a supplier group in 'Supplier. Define Purchase & Financial' (CRS624/E).
  Payee	... a range of persons or companies that receive the payment. A payee is entered for the supplier in (CRS624/F) if they are not the same legal entity. Several suppliers can have the same payee.
  Payment priority	... a range of priorities to be considered for the selection. You use this range when you want to include only suppliers with a certain priority in the proposal. Each supplier can be given a priority in (CRS624/F). These codes are used: A–8, where A is the highest priority. Code 9 indicates that payments are stopped for the supplier.
  Currency	... a range of invoice currencies.
  Invoice amount	... an amount range. You can only define this range if you have specified a currency in the previous field.
  Maximum payment amount	... the maximum amount due in local currency. By using this field, you can decide how much you are willing to pay right now. The proposal will then only contain invoices with a total amount up to and including this amount, discounts and credit notes deducted.
  Recurring payments	... whether only recurring payments are included, not included at all, or included together with ordinary payments. These payments are specified in 'Supplier Payment. Open Recurring' (APS095).
  Auto match of credit transactions in payment proposal	... whether credit transactions are to be matched automatically when a payment proposal is created in (APS130). Credit transactions in this context are supplier credit notes, supplier on-account payments, and – if the supplier also is registered as a customer – customer invoices to include for netting. If you select the check box, credit transactions are matched against supplier invoices, regardless of payment date, to avoid negative payments. The payment dates of the credit transactions and supplier invoices are automatically changed to the payment date of the last transaction. This procedure only includes transactions of these types: Invoices and credit transactions with payment methods with alternative 2 = 'Grouped per due date' selected in the 'Grouped payment code' field in 'AP Payment Method. Open' (CRS071) Invoices without a cash discount. This check box exists in both 'Settings – Accounts Payable' (APS905) and 'Supplier Payment Proposal. Create' (APS131/E). The value selected in (APS905) is proposed by default in (APS131).
  Corporate netting	... whether the supplier payment proposal is to be created only for supplier invoices with a corporate netting payment method. If you select the 'Corporate netting' check box, only supplier invoices with netting payment methods are selected. When you have selected this check box, you cannot select 'Ordinary payment', 'Recurring payment', 'Payment request', 'Payment type', and 'Match credit note' in (APS131). Negative payments are allowed if 'Corporate netting' is selected, then block code 3 will not be set on the invoices in the payment proposal. If you do not select the 'Corporate netting' check box, supplier invoices with netting payment methods are not selected in (APS131).

  Note: You can use these additional values when creating the proposal.

  Apart from the listed selection criteria, you can also define:

  • Whether bank quotas should be used to distribute payment orders (refer to the 1.6.2 Automatic Distribution of Payments between Banks section)
  • The proposed payment date, to be used if the invoice's due date is exceeded or if the Group payment code is 2 for the payment method used (refer to the 1.4.1 Grouped Payment Code section)
  • Next planned proposal date to optimize the cash discount (refer to the 1.3.4 Cash Discount section).
• Automatically netting AR invoices against AP invoices

  A supplier may also be a customer. If so, you may want the ability to net your debts and claims, then only pay the difference. By specifying the supplier customer number in (CRS624/E), the customer invoices of the supplier will automatically appear as credit invoices in the payment proposal, depending on whether you select the check box 'Auto match of credit transactions in payment proposal' in (APS131/E). Any credit invoices in accounts receivable (AR) are included as debit invoices.

  AR records are included with their full invoice amounts without deductions for VAT or cash discount. You can easily identify them: To each AR record in the proposal, the comment 'From Accounts Receivable' is added, together with the supplier's customer number.

  • Factors controlling what AR records are included:
    • The currency of the AR records must be the same as the currency or currencies selected for the proposal.
    • The AR records must not be blocked in 'Customer Invoice. Change' (ARS201).
    • Invoices cannot be netted if the payment method selected has the 'Grouped payment' code 0 (No grouping) – see below. The reason for this is that the netting is done against invoices with the same payment document number. With code 0, each invoice is assigned a payment document number. Consequently, an AR invoice included as a credit record cannot be netted against other invoices.
  • When the credit amount exceeds the debit amount:

    If there are only customer and supplier credit invoices in the proposal or the total amount of the credit invoices exceeds the total amount of the debit supplier invoices, the difference can be paid to the supplier. This applies to bonus or commission payments, for example. In what form this amount is paid (check, bank transfer etc.) depends on the default payment method for the supplier in (CRS624/F). That is, the original payment methods for the AR records are overruled.

    Example: The AAA company is registered both as a customer and a supplier. In this case, you have one customer credit invoice of SEK 1,000 recorded in your accounts receivable for AAA. You have also received and recorded a supplier credit invoice of SEK 600 from the same company. When you create the payment proposal, the customer credit invoice is included as a debit record, from which the supplier credit invoice is deducted. The result is that you pay AAA SEK 400 (1,000–600).

• Valid payment classes

  Only invoices recorded with payment methods under these payment classes can be included in a payment proposal: 2 (checks), 3 (manual or electronic bank transfer, 4 (drafts) and 5 (direct debiting).

• Blocked invoices

  Supplier invoices that are blocked in 'Accounts Payable. Change Separate Invoice' (APS201) are not included in the proposal, even if they otherwise match your selection criteria, but they are included in the error list printed when creating the proposal. The same is valid for invoices for blocked suppliers.

  Block codes in the payment proposal

  Invoices included in the proposal can be blocked, either automatically or manually. These fixed block codes are used:

  • 0 = Not blocked
  • 3 = Blocked, since the total per supplier to be paid is negative
  • 4 = Blocked, since the credit note or invoice is not due
  • 5 = Blocked, since the calculated cash discount will be the same for next planned payment
  • 6 = Blocked, since the bank account in the supplier invoice contains the wrong bank information.

  Block codes 1, 2, 7, 8, and 9 are user-defined.

  When the proposal is deleted or confirmed, all blocked invoices are released so that they can be selected in the next proposal.

• Cash discount

  Invoices with a cash discount date that falls within the date range are always selected, regardless of the invoices' due dates. This is provided that the cash discount date is today's date or later for the invoice. Cash discounts can also be applied to partial payments.

  Note:  If the cash discount date is not a bank day in the system calendar, it is automatically adjusted. This is done even if it means that the cash discount date is exceeded.

  You can optimize your cash discounts when creating payments. You wait to pay a supplier until the current cash discount period is exceeded. The result is that you accrue interest without losing the cash discount you are entitled to.

  One way of doing this is to specify the date for the next proposal run in the 'Next proposal date' field in (ARS301/E). Any invoices with a cash discount which would not have changed by that date are included in the current proposal, but with the block code 5. You then decide for each invoice whether to pay it now or later.

  You also have an almost unlimited number of options for managing cash discounts for a specific invoice in a proposal in 'Supplier Payment Proposal. Update Details' (APS137/E):

  • You can specify a cash discount date that is past the invoice's due date and/or today's date.
  • You can specify a negative cash discount amount or cash discount percentage. For example, if you want to pay back some cash discount that was not approved by the supplier.

  You can also specify negative cash discount amounts for an invoice in 'Accounts Payable. Change Separate Invoice' (APS201).

  When creating the account entries for the cash discount, the exchange rate for the payment date is used.

• Settings for cash discount processing

  When creating the proposal, you can control which invoices to include from a cash discount point of view in (APS131/P). This enables you to pay as late as possible and still obtain a full discount.

• Tolerance days

  Even if you specified a due date for an invoice, the due date can be automatically adjusted depending on the number of tolerance days. This number indicates how many days after the due date an invoice may be paid without extra charges.

  The tolerance days are automatically added to the due date provided that:

  • 'Grouped payment' code 0 or 1 is defined for the payment method.
  • Number of tolerance days is defined for the supplier in (CRS624/F).

  Example: You specify an invoice with the due date June 7. Since the number of tolerance days is 3, the due date is automatically changed to June 10. If you create a proposal for all invoices with a due date up to and including June 7, this invoice is consequently not included. You would have to change the due date manually back to June 7 in (APS201) to include it.

  Tolerance days for cash discount

  The number of tolerance days connected to the supplier is not considered if the invoice has a cash discount. In such a case, the payment date is the same as the cash discount date. You can define a number of tolerance days for cash discount specifically. For example, you do this when your supplier allows for extra time for managing payments without it affecting the cash discount you are entitled to. You specify the number of days in the 'Tolerance days out' field in 'Cash Discount Term. Open' (CRS077) for the cash discount terms connected to the supplier in (CRS624/F).

• Invoices with future rate agreements

  Invoices with future rate agreements can be included in the payment proposal routine. Such invoices can only be paid by the division that the invoice and future rate agreement belong to. Any invoices with a future rate agreement belonging to another division than the paying division in a cross-division payment are excluded from the payment proposal and printed on the payment proposal error list together with an error message.

Factors controlling how payments are grouped in the proposal

• Grouped payment code

  The payment method you selected when specifying the supplier invoices controls the payment document number and the payment date. The value in the 'Grouped payment' field in (CRS071/E) is the triggering factor.

  When you create a proposal, invoices with the same payment method or currency can be automatically grouped or listed separately. Each invoice group – or separate invoice – receives a communal payment document number listed in the proposal. For such number, a separate payment document is then created when updating the proposal.

  Alternative	Consequences
  0 = Not grouped	Each invoice in the proposal receives a separate payment document number. Payment date Due date Cash discount date, if the supplier has granted a cash discount Cash discount date + number of tolerance days (as defined in the cash discount terms) Due date + number of tolerance days (how many days after due date an invoice may be paid without extra charges), if that number is entered in (CRS624/F).
  1 = Invoices grouped as one payment per due date	All invoices with the same payee, payment date, and payee's bank within the proposal receive the same payment document number. Payment date The payment date is set the same way as for alternative 0.
  2 = Invoices grouped as one payment per proposal date	All invoices with the same payee and payee's bank are grouped. Since the payment date usually is the same for all invoices, the payment document number is not displayed in (APS137/B) or printed in the proposal. An exception is when several invoices for one payee have different bank accounts; then the payment document number is displayed in (APS137/B) to show one total per bank. This means that the payment document number is used for internal purposes only. Payment date The payment proposal date entered in (APS131/E) is used as the payment date.

• Payment date

  For past due invoices, the due date cannot be the payment date. In such a case, the payment proposal date you specified in (APS131/E) is used as payment date for those invoices.

  If the payment date is not a bank day, it can be automatically adjusted. How this is done depends on how the 'Adjustment days payment date' value is defined for that date in 'System Calendar. Open' (CRS900/E).

  The payment date is used as the accounting date when you confirm the proposal and create the payment documents.

• Numbering

  When working with payment proposals, several types of numbers are used to separate different groups of records:

  Type of number	The number indicates …
  Payment proposal number	... the number which automatically is assigned the entire proposal. It is used as an ID to identify the proposal in (APS130). The number is retrieved from number series type 80 under number series 0 in 'Number Series. Open' (CRS165).
  Payment order number	... a sequence number assigned to each proposal document. When the proposal is created, it is automatically split into several parts.. All payments with the same payment method and currency are included in one proposal document. Thus, the payment order number is a sub-number to the payment proposal number. If you change the payment method or currency for a payment in a proposal document, it will automatically be moved to another, matching proposal document. If such a document does not exist, a new one is created.
  Payment document number	... a number assigned one payment or a group of payments to be paid with one payment document at a specific payment date. (Refer to section Grouped Payment.) This number is only used to separate between the groups within the proposal document and always starts from 00001. When using payment methods for checks or drafts, each payment document number results in one printed payment document and one voucher.
  Payment reference number	... a unique number assigned all payments with the same bank, currency and payment date when paying through manual bank transfer, electronic bank transfer (EDI) or direct debit. Concurrently, these payments constitute a payment order to be sent to the company's bank. The reference number is used when applying a payment method with bank feedback. The number enables you to identify payments when reconciling them based on the bank statement in (APS190). The payment reference number is retrieved from 'Number Series. Open' (CRS165), number series type 89, number series 1. Manual bank transfer One payment order is printed for all records with the same payment reference number. The order also specifies the different statement numbers; see below. Each order receives a payment reference number. Electronic Bank Transfer (EDI) An electronic payment order is created per payment reference number. Due to EDI standards, the proposal records with the same payment reference number are always grouped per payee and the payee's bank, regardless of the 'Grouped payment' code (see above). How M3 is affected One voucher is created per payment reference number. The payment date is then used as the accounting date. The reference numbers are saved in these files: With information category number 409 in the detail file for accounts payable (FPLEDX) With information category number 216 in the detail file for accounts receivable (FSLEDX) In the detail file for the general ledger (for recurring payments without connection to a recorded invoice).
  Statement number	… a unique number assigned each payment document record included in a payment order for manual bank transfer. The statement numbers are listed in bank account order. The statement number is retrieved from 'Number Series. Open' (CRS165), number series type 67, number series A. How M3 is affected The statement number is saved in the detail files for accounts payable, accounts receivable or the general ledger, depending on the type of payment. (See under payment reference number.)
  Draft number	... a unique number assigned each draft payment. The number is retrieved from 'Number Series. Open' (CRS165), number series type 67, number series B. How M3 is affected See under statement number.
  Check number	... a unique number for a check payment. Since the checks to be used are already numbered, you only need to enter the check numbers in M3. You do this by entering the first check number in 'Check. Print' (APS140/E) when confirming the proposal. For each new check that is printed, this number is automatically updated with 1. Adjusting check numbers If you encounter printer jams when printing checks, you may have to adjust the current check numbers. You do this in 'Check. Change Number' (APS145). How M3 is affected See under statement number.

Adjusting payment proposal

You can change these values for each proposal document:

• Proposal document level

  Value	Comment
  Company's bank	This field refers to a specific bank account, not a bank in itself. The account can be changed if you indicated that bank quotas were not to be used when creating the proposal. Trade code break level and parallel invoice number are also considered if used in the proposal.
  Payment method	The payment method can be changed for the entire proposal document, all invoices within the same payment document number, or for a separate invoice. If the payment method has 'Group payment' code 2, you can only change to a payment method with the same code. For a list of valid payment methods, see above. Trade code break level and parallel invoice number will also be considered if used in the proposal.

• Invoice level

  Value	Comment
  Payee's bank	As in the case with the company's bank, this field refers to a specific bank account, not a bank. The account can be changed, provided that the payment method used belongs to payment class 3 (bank transfer) or 5 (direct debit).
  Payment date	The date can be changed, provided that the 'Grouped payment' code is not 0 or 1 for the payment method. The new date is checked against the system calendar; otherwise no other test is done. Any cash discount has to be manually adjusted or deleted.
  Payment method	See above.
  Cash discount	The cash discount date must be today's date or later. It is not possible to add cash discount if a cash discount was not recorded with the original invoice.
  Amount to pay	If you reduce this amount, the payment is recorded as a partial payment of the original invoice.
  Payment block codes	The block code is used to block the invoice from being paid. Alternatives 0 = Not blocked 3 = Customer stop (general block code) 4 = The due date is less or greater than the due date range selected when creating the proposal. This code is used for APL credit invoices only. 5 = The invoice is blocked since the cash discount is the same on the date selected as next proposal date. You can change codes 0 and 3. If you confirm a proposal with blocked invoices, these are released and can be included in another proposal.
  Trade code	This code is used in international trade to keep track of different categories of services, material, etc. for statistics purposes. They can also be used for domestic payments in a foreign currency if this is a legal requirement or a demand in order for the supplier to avoid having to pay a bank fee for processing the transaction. Trade codes are defined in 'Trade Code. Open' (APS010) and connected to the supplier in (CRS624). Trade code break level will be considered in the proposal if the combination of payment method and bank account ID of the proposal is defined in 'Payment Document Break Level. Open' (APS091). If not, ordinary grouping of invoices is used.
  Parallel invoice number	This additional payment reference is used to facilitate electronic payments. The parallel invoice number is available for invoices with payment class 3 and 5. If the payment method of the invoice is changed other than with payment class 3 and 5, the parallel invoice number is removed.

Bank information

• Company's bank

  You register your bank accounts in 'Bank Account. Open' (CRS692). By linking an account to a specific currency and payment method in 'Bank Account Connection. Open' (APS090), you do not have to specify a bank account when creating the proposal. Instead, it is automatically retrieved from the matching combination in (APS090).

  Your selection criteria in (APS131) are matched in this priority:

  1. Currency, payment method

  2. Currency only

  3. Payment method only

  4. Blank in both currency and payment method ("catch all").

  Note: If you use bank quotas, the bank accounts are retrieved from another program (see below).

  The cash account used to record the payment is retrieved from (CRS692).

• Automatically allocating payments to bank

  You can decide to use one or several bank to pay your suppliers. The allocation is automatically done if you have defined combinations of currency, payment method and bank in 'Bank Account Connection. Open' (APS090).

  You can also use bank quotas, a common alternative in Latin countries. A table of bank quotas is created in 'Bank Quota. Open' (APS030) and applied if you select the 'Use quotas' check box when creating the proposal in (APS131/E). For more information, see Create Bank Quotas for Automatic Allocation of Supplier Payments to Bank.

• Payee's bank

  When creating the invoice, the supplier's/payee's bank is retrieved from the bank account connected to the supplier in (CRS692). If there are several accounts registered for the supplier, the account with the highest priority is selected. The account is then automatically displayed for each payment record in the proposal, but can be changed.

  A bank ID cannot be specified for supplier checks.

Payment amount control

• Substituting payment method

  For the payment method in 'AP Payment Method. Open' (CRS071), you can specify that if the payment amount is greater or lesser than a certain amount in local currency, another payment method is used. The check is then done per payment document number level when creating the proposal.

• Currency

  The currency of the proposal document must either be the same as the currency defined for the bank or the local currency in M3.

• Exchange rate type

  The exchange rate type defined for the payment method of the invoice is applied in these cases:

  • When selecting 'Maximum amount to pay' in (APS131/E).
  • When confirming proposals with payments in foreign currency and no bank feedback is selected for the payment method.

  In cross-division payments in foreign currency, the general rule is that the exchange rate to use is the paying division's rate as specified in 'Currency. Open' (CRS055).

• Rounding off variances

  When the exchange rate has several decimals, small rounding off variances can arise between local and foreign currency. These variances are automatically posted on the accounting string defined for accounting option 99 in 'Supplier Payment Variance. Open Accounting Option' (APS020).

Voucher text

If you specify a voucher text when updating the proposal, this voucher text is used for all transactions. The only exception is for transactions on the accounts payable or accounts receivable account, where the voucher text from the original invoice is used. In a similar way, no voucher text is recorded if you leave this field blank when updating, with the same exception.

AP and AR Additional Information

To know the additional information of supplier and netted customer invoices and credit notes, use the 21= 'Additional info' related option on the (APS137/B) panel to display 'Suppl Invoice. Display Additional Info' (APS216) and 'Customer Invoice. Display Add Info' (ARS216).

Common error statuses

The error statuses are specified in the error report printed if any incorrect records were found when creating the proposal. Other invoice records not matching the selection made for creating the proposal are also included with error codes, depending on the selection criteria entered. This is done to indicate any excluded invoices that are also considered.

The error statuses used are:

For Sweden-specific error statuses, see Validity Checks for Supplier Payments via BankGiro and PlusGiro (Sweden).