A/P-A/R accounting > Payments > Doubtful receipt entry 

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

Presentation

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.

Close

 

Fields

The following fields are present on this tab :

Block number 1

Code of the bank for which the doubtful receipts and the bank charges are posted.

  • Accounting date (field ACCDAT)

Posting date of all the accounting documents that will be generated from doubtful receipts entered in the grid. The date of the current day is suggested.

Block number 2

 

  • Description (field DESVCR)

Header description of the accounting entries that are generated from the entry of doubtful receipts. This description is repeated in the lines description of the doubtful receipts entries.

 

Grid Details

  • Payment no. (field NUM)

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

The selection proposed is made based on the following criteria:

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


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

Doubtful receipt reason to chose in the list.

  • Description (field DES)

Description for each line of the entry generated when the payment is unpaid.
By default, the header description is displayed in this field.

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

  • RTZ declared sales tax (field AMTVATDCL)

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 this field 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 this field 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 (field BPCTYP)

The doubtful receipt entry is posted on the customer account if this field is set to No, or on the "doubtful customer" control account if the field is set to Yes.

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," the doubtful receipt entry is generated on a "doubtful customer" control account.

SEEREFERTTO See the documentation on the accounting accounts for further information.

  • If the customer is not considered "doubtful," the doubtful receipt entry is generated on the control account with which the payment is made.

The behavior for the matching is different depending on whether the company manages the VAT on collections (DCLVATPAY parameter) and whether the customer is considered as doubtful.

  • Cost (field AMTCRG)

This is the amount of charges invoiced by the bank and caused by a doubtful receipt entry or unpaid items. The amount is expressed in the currency displayed in the header (bank currency).

If the charges are expressed in a different currency to the payment, two entries are generated in accounting:

  • An entry is generated for the posting of the doubtful receipt entry in the payment currency (if the charges are on the same entry as the doubtful receipt).
  • An entry is generated for the posting of unpaid charges, in bank currency.

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

Charges can either be generated:

SEEINFO This field can be accessed if the payment has been posted by the bank.

VAT code that will be applied to the charges. Entering this field is mandatory if charges have been recorded.

  • Tax amount (field AMTVAT)

Amount of the VTA on the charges. This field is calculated but can be modified.

  • Reinvoicing (field IPTBPR)

This field is used to define whether the unpaid charges are allocated to the BP or the company. The values of this field are as follows:

No

The unpaid charges are charged to the company.

Yes

The unpaid charges are allocated to the BP.

In that case, these charges can be automatically reinvoiced through the creation of a customer BP invoice. This customer BP invoice is automatically created with:

  • the type of invoice specified in the parameter Unpaid re-invoicing entry type - TYPINVNDT (TRS chapter, UNP group),
  • the miscellaneous account 'Unpaid expense account' entered in the Miscellaneous accounts tab of the function Chart of accounts (GESCOA).

    That customer BP invoice can then be validated in accounting or deleted.

The setup determines if the analytical dimensions can be modified. They are initialized based on the setup of the default dimension.

In creation mode, if no order line has been entered and the project code is modified, the analytical dimensions are reset based on the setup of default dimensions.

In creation mode, as in modification mode, if an order line is entered and the project code is modified, the analytical dimensions are not reset.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Block number 4

  • Due date (field DUDDAT)

Due date of all the generated accounting entries. The due date of the payment that has been entered first in the grid is suggested.

Close

 

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