Weekly Dynamic: Cleaning up Received Not Invoiced

A while back, like almost 5 years ago, Frank Hamelly and Richard Whaley had an interesting discussion on cleaning up Received Not Invoiced transactions in GP. You can read the whole thing at: http://www.database-answers.com/microsoft/Great-Plains/33761991/proper-way-to-clean-up-received--not-invoiced-report.aspx

In my opinion, they are both right and they are both wrong. Let me see if I can clarify.

In a nutshell:

1) You authorize purchases with a  P.O. (no effect on GL)
2) You receive items into inventory. Debit Inventory (or Expense as appropriate) Credit Accrued Purchases
3) You match an invoice to a receipt (Debit Accrued Purchases, Credit Inventory). This creates and AP transaction for the invoice.

Anything received but waiting for an invoice shows up in the received not invoiced report commonly called RNI. (Step 2 above). Receiving the invoice clears accrued purchases and let's you pay for the item. Until you match a receipt to an invoice, the receipt is in limbo and the only real tools to manage accrued purchases are the Received Not Invoiced report in GP and the Received Not Invoiced SmartList.

So what happens if:

1) an invoice is never going to arrive?
or
2) the invoice arrives and is mistakenly paid directly via AP, not applied to the receiving transaction?

There are 2 broad ways to clear a receiving transactions and a number of techniques and gotchas along the way. Regardless of the way you close the transaction there are 3 considerations,

1) the RNI report.
2) the Accrued Purchases account.
3) AP

If you don't do this right, one of the first two items will be out causing accrued purchases to not balance to the GL or AP will get a transaction causing a risk of double payment.

Broadly the options fall into two categories:

1) Close the P.O.
2) Fake an invoice.

Closing the P.O. or the appropriate P.O. lines properly removes items from the RNI report and while it can generate a related GL transaction, it doesn't in the typical scenario.

Faking a invoice properly removes items from RNI and accrued purchases but it creates an AP transaction which requires additional work to clear and introduces a risk of double payment.

So here is my recommendation based on the common scenarios:

1) Item received. Invoice will never arrive (usually some kind of internal transaction).

Do an invoice match transaction. Enter the subtotal into the trade discount field to offset the subtotal and create a $0 value invoice. Adjust the trade discount account for appropriate offset (often an intercompany account). This will NOT send a transaction to AP and it will clear the transaction from the RNI report and move accrued purchases. You will need to confirm that the other side of any I/C transaction is correct.

2) Item received. Invoiced arrived and posted to Inventory or Expense via AP. (This is probably the most common scenario I see.)

You've now doubled up the debits. (Receiving and AP). Do an invoice match transaction. Enter the subtotal into the trade discount field to offset the subtotal and create a $0 value invoice. Adjust the trade discount account credit to the Inventory or Expense account that was doubled up. This will NOT send a transaction to AP and it will clear the transaction from the RNI report and properly clear the accrued purchase.

3) Item received. Invoiced arrived and posted to Accrued Purchases via AP (This what you hope will happen but if AP figured out it belongs in Accrued Purchases they should have figured out that it needs and invoice match!)

The GL is correct. Close the P.O. or P.O. line to properly adjust the RNI report. Closing the P.O. line should not create a GL transaction.

These are my preferred options. They avoid the mess.

If Trade Discount isn't available because you actually use that field AND track the discount for reporting purposes it gets harder. Your choices then are to match the invoice, send it to AP and create a credit memo.

You could also close the P.O. or P.O. lines and then do a journal entry to fix the accrued purchases account but normally you don't want to do JE's to this account, it's considered a control account and it's still two transactions.

I've been arguing for a Historical Received Not Invoiced report to help manage this. If you want one too. please go vote for it at MS Connect. The vote link is: Connect.https://connect.microsoft.com/dynamicssuggestions/feedback/details/778666/gp-historical-aged-received-not-invoiced-report