I was at the NAVUG user group in NYC last week. There, I learned that NAV2017 now allows users to cancel posted sales invoices and sales credit memos. While I’m sure some users will welcome these changes (and I’ve yet to see exactly how they’ll work), my first impression is that this isn’t such a great idea.

Part of my reasoning is that, honestly, I believe that people who “pay for their mistakes” are more likely to stop making them.

But I also hesitate because I don’t like reversing transactions in NAV more generally.

Using Reverse Transaction in Dynamics NAV

NAV has at least three “reverse transaction” options: General Ledger Entries, Customer Ledger Entries, and Vendor Ledger Entries.

When a customer bounces a check, you could usually reverse that in the customer ledger.

To better understand my hesitation about reversing transactions, let’s look at a payment reversal as an example.

Let’s start with payment 2596 (below) in the Dynamics NAV Cronus USA database.

Click Applied Entries to see where this payment was applied:

And here’s the invoice:

So, we see this payment was applied against one invoice.

Let’s see what happens when we choose Reverse Transaction:

This is what shows up:

As you can see, there are three customer payments on the same date with the same information, which is confusing.

But the key issue is that your only option to continue is by clicking “reverse.” You can’t control the posting date—it automatically goes back to the original date of the payment. This creates several issues:

  • If you have proper date controls in place, you can’t post the entry at all. This means reverse transaction only works when the period is open. (See my post Month End Closing in Dynamics NAV for more on this.)
  • Even if you’re in the same period, report numbers will change in unexpected ways.
  • At best, you’ll need to have two different solutions.

My Alternate Solution for Dealing With a Bounced Check

Here’s my suggested method:

  • Choose the appropriate payment and click “Unapply Entries”:

When you do, this page appears:

Strangely, on this page, you can control the posting date. (Even though from an accounting standpoint, Unapply Entries doesn’t effect any ledger balance, while Reverse Transaction does.)

Click “Unapply” at the top of the page.

Now, the payments (and matching invoices) show as unapplied:

After we’ve unapplied the entries (so the next good check from the customer can be applied correctly), we can “refund” through a cash receipt journal and “apply” this refund to the now-open payment.

We create the refund here:

Then, we click Apply Entries and get to this screen:

We can use this process at any time—regardless of when the customer check bounced.

A side note: I somewhat accept that reversing general journals isn’t the worst thing if you’re doing it to correct an error on your part. However, I’ve had many occasions where people ask, “Why did this report change?” when someone reverses an entry just a little too fast.

What’s your process for dealing with NSF checks?


Get tips and insights delivered to your inbox

Start a conversation with us

Call: 917-848-7284
Email: inquiries@redthree.com

Request a Consult