The Customer Payment process is used for entering customer payments through the various payment institutes. Offsets can be entered at the same time as payments. These can be offsets between debit and credit invoices, between invoices and payments on account or between invoices and payments in advance. When you save a payment, a voucher is generated automatically to the hold table in IFS/Accounting Rules. The voucher belongs to voucher group B and contains postings for customer claims, cash transactions, bank fees and currency differences.
The system allows the entry of multi company customer payments and to use deduction. This is a function that covers payments where customer invoices are produced and stored in several individual companies, but customer payments are received and entered in only one company. A benefit of this is that a group of companies can use centralized cash application.
When payment transactions are entered, you can preview the postings. You get a general idea of how the amounts in the entered currency and the accounting currency are distributed among the various accounts and posting types.
There is a Select Batch operation in Customer Payment and Customer Offset. This operation is used to select several invoices and/or prepayments at the same time.
When a payment is matched with an invoice, the tax
amount in the invoice will be posted to the code strings defined for the
following posting types:
When a payment is entered and matched with an advance invoice, the postings would be different. The tax amount included in the advance invoice will be posted to the code strings defined for the following posting types:
The tax amount connected to the automatically created payment in advance will be posted to the code strings defined for the following posting types:
There is a function for entering pre-posting for new payments on account. Pre-posting can be defined for all code parts separate from the account, i.e., the free code parts B-J. Pre-posting affects the customer claim if this posting type is opened for it. Pre-posting also affects the connection with offsetting currency rate differences if these posting types are opened for it.
When the tax type is Payment, it is possible to apply the correct tax currency rate. As a result of this adjustment, there will be a currency gain or loss, for which the posting types PP62 or PP61 are used respectively.
The bank fee, if any, can be entered in the payment and accounting currencies if the two are different. In Posting control, you can enter how the company’s bank fees are to be posted. The same posting rule is used for the bank fee in both currencies if they differ. The account for transfer posting is also controlled by posting control. It is advisable to look at the transfer account balance and distribute it between the correct accounts. The transfer account is a temporary account. You can work on posting of the transfer account, in order to have it be zero (0), in voucher entry in IFS/Accounting Rules.
General Information - Payment functions: The system includes functions that support various types of payment. Each function is linked to a payment type. All these functions generate payments within the system. This means that the system considers offsets and rollbacks of payments to be payments in the same sense as ordinary payments.
A payment consists of three main parts: Payment Transaction, Cash Transaction, and Voucher.
Payment transactions define which items have been paid, offset, or undone. These items can be invoices, payments on account, payments in advance or parked payments.
If the payment includes a cash flow in relation to a payment institute, a cash transaction is also generated. There are special search facilities for cash transactions that enable flows to be followed in the company’s cash accounts.
Each payment generates a voucher. The voucher includes all
postings for the payment. When a payment is canceled, a correction voucher is
generated.
General Information - Identification of
payment: Each payment within the system is given a unique ID consisting of
the payment series ID and a number within the series. Different payment types
can be linked to different series. This means that different types of payments
can be kept together if necessary. There must be at least one series for
customer payments and one for supplier payments.
Payments on account are identified from a separate series.
Additionally, each payment will be given a unique ID and a date, both of which will also be assigned to all the invoices matched with the payment. The invoices and their matching payments will be included in relevant queries and reports together, along with their matching ID, so you can easily identify which payments are connected to which invoices.
General Information - Payments on account, payments in advance and parked payments: A payment received can be entered as a payment on one or more accounts. When the payment is saved, each payment on a different account receives a new ID (as described above). Payments on account and payments in advance won't receive a matching ID until they are matched with an invoice. Parked payments will not receive any matching ID since they are not connected with any customer.
A parked payment is a special form of payment on account or payment in advance, entered without links to customer or supplier. A payment on account or a payment in advance is a payment with a link to a supplier or customer but with no link to an invoice. A partial rollback will create a parked payment.
For customer payments, part of a payment can be parked if you want to make a break in the entry but still want to save the payment in the system. Part of the payment can also be parked if the origin of the payment cannot be identified, e.g., an unknown customer or customer invoice. A difference item invoice (IP21) can be created from the remaining amount on a Partly Paid Invoice, and a difference notice is sent to notify the customer.
For a partial rollback, no cash transaction record is generated. The total amount of the rollback is set up as a parked payment so that it can be offset against relevant items, invoices, or later payments on account. In essence, a parked payment is a payment pending completion. The parked payment is, however, fully posted in the system in the same way as other customer claims and supplier debts. It is a good idea to use a separate ledger account for parked payments.
General Information - Roll-back of payment: You can cancel-rollback an entire payment or part of a payment, the cancellation rolls back the payment and posts the invoices and pre-payments as unpaid. You can post the entire payment as unpaid all at once or just certain invoices or payments on account. A complete rollback will completely reverse the payment, including the cash transaction. It also will cancel any difference item invoices created for the payment. The matching ID will also be removed for the specific payment and related invoices. A partial rollback will only reverse the payment of specific invoices, and a new parked payment will be generated for the reversed cash transaction. In this case, the matching ID will be reverted back.
It is also possible to rollback the Transfer to Bad Debt and Transfer from Bad Debt payment types. Only full rollback is available for these types of payments. A standard rollback voucher is created with normal postings or with correction posting, depending on the parameter entered in the Cancel/Rollback Posting Method field in the Accounting Rules tab of the Company window. No posting control is involved in this rollback, it is simply a reversal of the existing ledger posting. The ledger status for invoices/difference items included in the rollback of a Transfer to Bad Debt is changed back to Normal, while ledger status for invoices/difference items included in the rollback of a Transfer from Bad Debt is changed back to Bad Debt.
Before you start entering customer payment information check that Basic Data Required (BDR) has been set up as per instructions in Define Financials Basics, the Set up Basic Data Mixed Payment process.