Hi @cmanhoff For the below question on #3 in the diagram, the accounting entries are correct when the Refund is created for an already received payment in Acumatica. Will review the remaining details gain, and provide you the workarounds in Acumatica.
It should be read as below:

Cash or Bank - Decreases for Credit (Accounting principle of Asset Credit will actually decrease) and 

AR - Increases for Debit(Accounting principle of Asset - Credit will actually decrease)

Hi @cmanhoff Please find the below details and kindly let me know if this works for you as per your expectation.

The approach for achieving the below mentioned flow is to directly record the Cash Refund in the Banking Module of Acumatica. A Cash Transaction of Disbursement Entry type can be recorded to affect the below accounts, as expected by you. 

 Dr. Sales

 Cr. Bank (or Cash)

<@cmanhoff]Refunds involve cash payments to customers.  As such, there should be no entries ever to AR; the AR is closed and paid.   Otherwise, if you haven’t received the cash yet, you can just issue a credit memo to an open invoice or balance and you’re done.  Making entries to any AR account for a refund is just going to pollute your books.

Screenshots for reference showing the Acumatica Cash Transaction and Journal Entry:
Step 1: Create a Suitable Entry type for Cash refund in the Banking Module.,
 

Step 2:Add the entry type to the Cash Account
 

Step 3: Create the Cash Transaction for the Refund:
 

Step 4: Release and review the Journal Transaction for the above cash transaction.

This will appear in the Bank reconciliation statement for reconciling.

Hi @cmanhoff In Acumatica, we can also perform the Customer Refund in AP module by converting the Customer to a Vendor.

Step 1: Goto the Customer and Convert to Vendor. For this Vendor, you can have the “Customer Refund Payables” as Payable Account

Steps 2: Record a Bill or Credit Adjustment in the AP Bills and Adjustments screen

Step 3: Pay the Customer(now Vendor in AP) like usual

Thanks

Chandra

Chandra,

Thanks for your replies.  Let me reply to them in turn:

In the first reply, you are absolutely correct.  I made in error in my original post.  The refund does not increase cash as I stated:  a credit to cash of course reduces it and I should have said “decrease”, not “increase”.  However, since it doesn’t link it to an true cash disbursement, like sending a check, my concern is that you will later double the cash deduction when a payment is actually issued. This will still lead to reconciling issues and the need for correcting GL entries later.

As for using the Cash module, I haven’t reached that section yet in my training, so I’ll take your word on the specifics.  As far as general accounting design (as opposed to systems design), as a controller I’d require that handling through the cash app be subject to three requirements:

1.  Transactions handled through cash should be limited to actual cash transactions, e.g., cash refunds issued immediately in a retail setting.  Since the training is refererring to regular AR invoice issuance, this would not really be the appropriate module.
2. Regardless of the refund method, or which module, refunds should always be subject to review and approval by a supervisor before the refund is issued, at least over a certain amount.   Generally, you’d want this as part of the POS system e.g., store manager approval before the customer is paid the money. 
3. You also need to capture the underlying transaction (i.e., the original sale) as part of the audit trail.

Is the Acumatica cash module capable of handling the last two automatically?

The last reply suggesting that it be treated a payable makes the most sense in the absence of a systematic refund process.  It’s how I’ve always set it up in businesses that normally use AR (as opposed to cash)  and would in an Acumatica deployment. 

The only drawback is that you can’t really link it systematically to the original AR.  This problem that can be overcome by requiring the person processing to provide that information in the details.  But it relies on manual controls which always add time to do and then additional time to verify.

It just seems like there is an opportunity being missed here to automate and strengthen these controls, as well as making the refund process faster.  Acumatica has already gone to the trouble of creating a refund method.The mechanism is here automatically to:

1. capture the audit trail, including the underlying sales record
2. enforce that only existing sales transactions can be used for a refund
3. automate the approval process and
4. properly handle the accounting entries (e.g.  posting properly to A/P and Sales accounts instead of cash and AR accounts). 

It just doesn’t seem to be set up that way.  I’m sure clients would really appreciate this feature if it worked right, and I have seen comments to this effect in other postings. 

One last note.  I’m referring to a service-related refund process here.  Warranty and returns would need slightly different treatment since they also impact inventory accounts.  

Again, thanks for the help.   

Chris

The Process  of Overpayment and Advance Payment to Customer / Vendor is totally  not upto the industry best Practices or is more Complicated in Acumatica .  The Customer or Vendor account need to have an additional  Field for Open Account Payment linked to a Down payment / Advance Payment Received /Paid Account .  or the un applied Payment amount need to get recorded in any of  other account other than AR/AP which helps to issue a Credit or debit memo to Customer / Supplier without processing a Refund  . there is no option i find to issue a Credit memo to customer for overpayment .