Functionality to create bad debt provisions for customer transactions that are more than X amount of days overdue.

To have

Prerequisite: A field in AR parameters for bad debt provision posting profile.

  1. A periodic task where the user can search for customer transactions based on due dates and customer attributes.
  2. The selection should provide a list of open transactions to be selected for bad debt provision.
  3. A Post functionality of the final list will create a transactions where the original amount on the AR Summary account is reversed and posted to the account specified on the bad debt provision posting profile (see prerequisite).
  4. Partial provision of a transaction would be ideal.
  5. A workflow for ensuring validation prior to posting would be ideal.
  6. A new field is needed on the customer transactions to mark if a transaction have been provisioned. Any transactions marked, will not be used in step 1-2.
  7. It should be possible to filter on that field for customer statements, and aging reports.
  8. If a customer transaction marked with provision is settled, the provisioned amount should be reversed back to the AR summary account.

The following additional functionalities are impacted by this feature:

  1. Settle and unsettle transactions
  2. Foreign currency receivable treatment.
  3. Only debit balance should be provisioned
  4. Partial payment should reverse the bad debt partially.
  5. Excess payment should not reverse the bad debt in excess
  6. Bad debts provisions are decided only at the time of book closure, the book closure might be happen in the future date and provision values to be decided as of the book closure date. For example book closure for 2022 is on 31/12/2022, the actual calendar date for book entries finalized is on Feb 2023. Being in Feb 2023, the system should support to know the back dated outstanding as on 31/12/2022 to create provision as on 31/12/2022

Provisioning bad debt is a standard business process, which we've seen requested on multiple clients. Microsoft does not support this and suggests using a manual general ledger journal. That does not specify exactly which transactions have been provisioned, and it does not reverse if the invoice is eventually paid.

Additionally, the AR summary account is typically marked as "do not allow manual entry", which stops the GL posting.

Needs Votes