Use this function to identify customer doubtful receipts linked to payment incidents for validated payments deposited in the bank. This function represents the last stage in customer risk management.

The account type used when posting entries varies according to whether the customer is defined as doubtful or not. It is also possible to define:

  • Who is charged with doubtful receipt expenses
  • Whether the expenses must be generated on an accounting entry other than the doubtful receipt
  • Whether the expenses must be submitted to a customer re-invoicing

The management of doubtful receipt entries has important consequences on the VAT declarations on collections. Therefore, there are various consequences on the doubtful receipt entries:

For a company not managing VAT on collections

DCLVATPAY setup = No

Enter doubtful receipt entry – RTZ of declared sales tax = No

Enter doubtful receipt entry - Doubt. Customer = Yes

Enter doubtful receipt entry - Doubt. Customer = No

* Invoice matching / Payment retained

* The doubtful receipt entry is the new open item to pay.

* Invoice un-matching / Payment

* Payment matching / Doubtful receipt

* The original open item is the new open item to pay.

For a company managing VAT on collections

DCLVATPAY setup = Yes

Enter doubtful receipt entry — RTZ of declared sales tax = No

Enter doubtful receipt entry — RTZ of declared sales tax = Yes

Enter doubtful receipt entry - Doubt. Customer = Yes

 

Enter doubtful receipt entry - Doubt. Customer = No

Enter doubtful receipt entry - Doubt. Customer = No

* Invoice matching / Payment retained

* The doubtful receipt entry is the new open item to pay.

 

*Invoice matching / Payment retained

* The doubtful receipt entry is the new open item to pay.

*Reduced matching of invoice/Payment/Doubtful receipt group

Prerequisite

SEEREFERTTO Refer to documentation Implementation

Screen management

Entry screen

Header

Bank

This is the bank assigned to the payments to be processed and thus the bank where the doubtful entries are posted.

The processing of doubtful entries can only be carried out on one bank at a time in the original payment currency.

Accounting date

This is the accounting date that is given to accounting entries created by the process. By default, this field is initialized with the current date.

Title

You can enter a description specific to a doubtful receipt or keep the one suggested by default (BANK doubtful receipt on ACCOUNTING DATE).

Entry lines

Payment number

You can manually enter a payment number. A selection screen (called by the contextual menu) is used to suggest a group of payments corresponding to the defined criteria.

The selection proposed is made based on the following criteria:

  • Payment type: limit the selection of the suggested payments to a single payment type.
    Only this criteria is mandatory, the following selection criteria are optional and are used to refine the suggested payment selection.
  • BP
  • Payment site
  • Payment currency
  • Total amount of the payment
  • Payment due date
  • Payment reference

The Bank field in the selection screen is automatically initialized because only the payments recorded for the bank defined in the header can be processed.

Reason/ Reason title

Define the doubtful receipt reason here. All the possible reasons are defined in miscellaneous table no. 310 and are represented by their own numeric code.

Title

You can enter a description on the line. The header description is used by default at the line.

RTZ of declared sales tax

This field depends on the DCLVATPAY - VAT on collections parameter (CPT chapter, VAT group):

  • If the VAT on collections is not managed, this field is automatically set to No.
  • If the VAT on collections is managed, this field is used to indicate whether to re-zero the VAT on collections initially paid or not.

If the field RTZ declared sales tax is set to Yes, then behaviors are the following:

  • The Doubtful field is forced with the value No and the doubtful receipt entry posting is automatically posted as a debit on the customer account.
  • The payment and original invoice are unmatched to insert doubtful receipt in the reduced matching.
  • This operation is considered to be unmatching with regards to the VAT on collections.

If the check is submitted to collection, it is assigned on entry to a payment entered as doubtful:

  • An uppercase matching is replaced by a lowercase matching for the invoice matching group, 1st payment, doubtful receipt entry, and 2nd payment.
  • The VAT is re-declared for the matching group produced this way.

If the field RTZ declared sales tax is set to No, then behaviors are the following:

  • Regardless of the value of the Doubtful customer field, the invoice matching/1st payment is kept.
  • The doubtful receipt becomes the new open item to pay.

Doubtful

This defines if the customer is doubtful or not. This information has an impact on the account types that will be used at the time of posting the doubtful receipt entry.

  • If the customer is "doubtful," then the doubtful receipt is generated on a "doubtful customer" control account (see documentation on accounting codes).
  • If the customer is not considered doubtful, the doubtful entry is generated on the same control account as the one from which the payment was made.

According to whether the company manages or not VAT on collections (DCLVATPAY parameter), the fact that the customer is considered as doubtful or not, leads to different matching behavior (see Introduction).

Expenses

Enter the amount of expenses generated by the doubtful receipt. The amount is expressed in the currency displayed in the header (bank currency).

If the expenses are expressed in a currency different from the payment, two entries are generated in accounting:

  • One entry is generated for the posting of the doubtful receipt in the payment currency, if the expenses are on the same entry as the doubtful receipt.
  • Another one is generated for the posting of doubtful receipt expenses, in the bank currency.

If the cost account is analytically tracked the posting fields must be entered.

In addition, the charges can be generated either in the doubtful receipt entry or a separate entry based on the value of the TAXUNPAY - Unpaid items on distinct entry parameter (TRS chapter, UNP group).

VAT/VAT amount

The doubtful receipt entry expenses are subject to VAT. It is therefore necessary to define the appropriate tax code. The VAT amount is automatically calculated.

Re-invoicing

The Re-invoicing field is used to determine whether the doubtful receipt expenses are allocated to the BP or to the company. This information also has an impact on the doubtful receipt posting: doubtful receipt expenses are posted (or not) as a charge for the company. If doubtful receipt expenses are charged to the customer, these expenses can be subject to an automatic re-invoicing by creating a customer BP invoice.

This customer BP invoice is created automatically with:

This customer BP invoice can then be posted to accounting or deleted.

Analytical posting

If the expenses are analytically tracked, define the analytical allocation linked to the expense.

Due date

You can define the due date for the journal entries generated by the process.

Limitation

The matching and unmatching process executed during doubtful receipt entry relies on information entered in Payment receipt/entry (GESPAY) in the Allocations grid. This applies to companies whether they are managing VAT on payments or not. That is, the DCLVATPAY – Manage VAT on collections parameter (CPT chapter, VAT group) is set to Yes or No and the RTZ of declared sales tax field is Yes or No.

A payment is entered and matched to an invoice, INV01. Then, the payment and invoice can be unmatched using the Manual matching (LETTRAGE) or Unmatching (DELETTRAGE) functions. Finally, the payment is matched to a different invoice, INV02. The doubtful receipt entry process considers information stored in Payment receipt/entry (GESPAY), that is to say INV01. Therefore, the matching/unmatching process then executed cannot work as described for standard use cases.

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

You do not have access to the bank xxxxx.

The user profile does not authorize access to the Doubtful receipt entry function for the selected bank.

Function not authorized

The user does not have access rights.

Bank account xxx record does not exist

The entered bank does not exist. You have to create the bank.

Payment number does not exist

This payment number cannot be found in the PAYMENTH file.

Payment number has already been entered

The payment has already been entered in the grid.

Payment already a doubtful receipt entry

The payment has already generated a doubtful receipt entry.

Doubtful receipt entry impossible: Payment neither in cash management, in the account nor deposited in the bank

The payment must be processed in one of the three stages (cash management, intermediate deposit, bank deposit) to be entered as a doubtful receipt.

Bank assigned to the payment xxx

A different bank to that entered on the screen has been assigned to the payment.

This is not a customer

The BP entered is not a customer.

Mandatory VAT code

If the charges are posted, it is necessary to enter the VAT code to be applied.

You do not have the rights for this site.

You do not have access to the payments carried out for this site.

Payment entry not found

The account entry related to the payment does not exist. It has been deleted or the entry number is incorrect.

Tables used

SEEREFERTTO Refer to documentation Implementation