Skip to main content

Notifications

Backout or Correct Journal Entry

Today’s #TipTuesday is the “cousin” of last week’s tip on the Copy Journal Entry feature, the Backout or Correct Journal Entry feature in Dynamics GP. This week’s tip was introduced in GP 8, so it too has been out for quite a while. I love this feature and I find many users are still manually reversing or correcting journal entries without utilizing this. The best part about this is the control – a user cannot backout the same entry twice and the original entry plus the new entries are forever linked with the history of any backout and correction. Doing these types of corrections manually means there is always room for error, always questions of “did this ever get corrected?”, etc.

What is it?

There are 2 parts to this one.

1. The Backout feature is to reverse a journal entry. Not to be confused with “a reversing journal entry” (LOL), backing out is just what it sounds like: selecting a previously posted journal entry and reversing it. If you forgot to make an entry “reversing”, this would be a good use to the Backout feature. Most times I suspect users want to Backout and Correct…

2. The Backout and Correct feature is a 2-part (2 transaction) function: create a reversal of a previous entry and then create it again, to be corrected, leaving it in an editable mode for the user to change what needs correcting.

What are the limitations?

I’ll refer you to last week’s post for this, as the list of what you can and cannot copy is the same for what you can and cannot backout. (Go to the “Can I copy anything?” section).

Plus there are 2 more things you can’t do, which I’ve alluded to in my introduction above:

  • Journal entries that have been backed out already (using this feature) cannot be backed out a second time.
  • A backout journal entry also cannot be backed out. Huh? See below for an example… it sounds worse than it is!

How do I use it?

Start with opening the Transaction Entry window (Financial navigation page > Transactions > General), then click on the Correct button (without entering in any other information).

First, select the proper action – “Back Out a Journal Entry” or “Back Out a Journal Entry and Create a Correcting Entry”. The first option creates 1 entry, the second option creates 2 entries. I chose the 2nd option.

Next, select the year and enter or look up the Journal Entry number to be backed out. Clicking OK will bring a user back to the Transaction Entry window with an “unposted backout” entry (reference 2 below).

A backout entry is mostly non-editable. Why? It’s intended to be a reversal of the original entry. If the accounts and dollars were editable, it wouldn’t hold the audit trail of being an exact reversal. The 2 things that are editable are the date (in case the original period is closed, for example) and the description. Notice even the journal entry type is greyed out (Reference 1 in my pic, Standard vs. Reversing). By default, the Reference will say “Back Out Journal Entry XXXX” unless you type in something to override that.

If you just want to back out an entry, save or post this and you’re done. If you chose Backout and Correct, as soon as you post or save, the “correction” part will appear in the window. The Correct part is fully editable – type, date, dollars, accounts – anything is changeable. At this point Dynamics GP has no idea what was wrong with this entry in the first place so it’s a perfect copy of the entry you just backed out, you need to change something here now or it will simply re-create the exact same transaction you just backed out! The default Reference is “Correct Journal Entry XXXX”.

In my example, I pretended that this was supposed to be a month end entry and changed the date to Apr 30th from May 9th, saved it to a batch and then posted the batch. For my purposes, I assumed everything else was fine, except the date.

What does it look like after posting?

After posting a backout and correct, an inquiry to that transaction will look like this. If an entry was backed out and/or backed out and corrected, there is an audit trail linking those together and it will look like this. There are hyperlinks to each of those entries and if you click on them, you will also see an “Originating JE” field.

One interested side note: someone asked a question on last week’s post about whether copying/correcting copies all of the subledger information if you copy a subledger transaction. The answer is: it does! Here’s an excel screenshot where I exported some data from the Account Transactions SmartList including some of the most common Originating fields, to prove that it did copy that data.

Common Errors

Here is what will happen if you attempt to back out the same journal entry twice: the message that appears will be “A posted back out or correcting journal entry already exists for this original journal entry. Select another record”.

Similarly if I select the journal entry that backed out my example above, JE #3484, I get this message “The record you selected backed out another journal entry. Select another record”.

This makes sense, mostly! If a journal entry has been corrected already, you don’t want users correcting it a second time. The second error is a little different, it’s preventing a user from reversing a backout essentially. This one is tough, as there may be times where a user backed out the wrong entry by mistake and there’s no fixing that via this method, unfortunately.

What is allowed is if you goof up on the correction, that entry is allowed in the backout and correct window. In my example, I can backout or correct JE# 3485 if I really wanted to. It wouldn’t be the first time I’ve seen someone “correct” an entry multiple times because they weren’t paying attention to the first correction! (not that I’m using personal experience on that one or anything!)

Otherwise the same messages will apply if you’re trying to backout or correct a sub-ledger transaction (see last week’s post for more on that too). That behaviour is controllable via General Ledger Setup.

That’s it for this tip!

Comments

*This post is locked for comments