Is it appropriate for the OPS dept. to go behind the scene and delete a receipt of goods entry due to error after the receipt has been posted and not notify
Is it proper accounting procedures to go in behind the scenes and reverse a 3 way match invoice after it has been posted?
Answers
No. Why do they have this capability? Very weak controls!
Basic accounting & control procedures. All transactions are recorded, leaving an audit trail. No deletions allowed. Corrections come in the form of JEs.
In a word, no. This should be reported and resolved within the company management hiearchy. The company
No.
All
I agree that the audit trail must be preserved: original entry, reversal and correction.
I'd add the following:
1. What do you mean by "OPS dept. to go behind the scene and delete a receipt of goods entry"? What is "behind the scene" really mean? If, for example, an Ops user was able to delete the original entry in your accounting/ERP system,you have a severe internal control issue. Who gave them user access to do that? Or, did they ask IT to access the database directly and delete-which is even worse from a system control perspective.
2.I would not use a journal entry (as that would impact the GL only). Your PO/AP process within the system should allow you to reverse an incorrect entry, and to post the transaction correctly. Map it out, ask your software vendor or look to your online help or
Note: some ERP systems offer the "delete" function as an option within the User Security administration features. It's a carry over from using the starter accounting systems (I won't name names) where you can delete a transaction. Best advice I can give is that you disable that feature ASAP.
What if the Receipt is posted and accounting has not processed the invoice yet? Would it be appropriate to delete or modify the Receipt if you are the warehouse Lead? To answer the other questions on who gave OPS the control was the COO.
Anon
Do you suspect someone is trying to make out that there never was a receipt of the item for some questionable reason? Have you asked why they simply don't follow normal practices in reversing what is wrong and re-posting what is right?
The answer is NO. To understand why, let's step back for a moment and look at the way the process should work with a good system of internal controls in place.
First, the Receiving department (Warehousing) answers to the Purchasing department. In that capacity, the Receiving department is there to receive orders placed through Purchasing (and perhaps enter those receipts into the accounting system). Period.
Once entered into the accounting system, those receipts affect inventory and purchasing. Eventually accounts payable is also affected through entry of accrual or vendor invoice.
Once items are received against a PO, the physical documentation (receipts, bills of lading, etc.) should be forwarded to Purchasing for further processing. If a Receiving department error is discovered, it should be documented and this documentation should be forwarded to the Purchasing Manager for further disposition -- which may also involve the
Now that we have explored why Warehouse personnel should not delete or modify a receipt, perhaps it would be more productive if you would tell us exactly what error was made and how it was handled. At the very least, this might allow us to formulate an answer that is more precisely aligned with your problem.
The answer is 99.9999% of the time the answer is a resound NO. You shouldn't go into the database and change information. As others have said, you should use the user interface to accomplish fixing the error.
0.00001% of the time it is a software glitch, and no amount of user interfacing can fix the error. This would be the only time to use the backend to adjust the data, and it should be DOCUMENTED and signed off by all those involved.
Len, to answer your question the OPS department is trying to avoid having to make the correction the right way as it will mess with their metrics of being flawless.
I want to thank all of you for your responses. I already knew the answer is no and I have explained this to the Receiving person and the Buyer/Planner person. My next step is to reach out to the COO who has given the Admin rights to the Buyer/Planner and Director of Supply Chain-OPS. They are the ones who are requested to have this option available and they are stating it is a normal function to alter or delete a Receipt after it has been validate to make corrections as needed.
My only dilemma is how to professionally and appropriately approach this with the COO and the President. They are not Accounting/Finance educated, therefore, at times it is hard to have a conversation and explain things are not okay to or perform.
If you have an Internal Audit or Internal Controls Group, you could bring the issue up with them. I'm sure that they would be happy to document the issue and bring the necessary parties together to tighten those controls up.
One way you can approach this with the COO and President is to point out that by allowing the OPS department to fix an error this way, their metrics are off. Errors are inefficient and lead to higher number of hours worked versus doing it right the first time. By hiding the errors, they are hiding opportunities for improvement. You are right that all the control language which means so much to us can make COO's eyes roll. Putting it terms of efficiency, or lack thereof, and opportunities for improvement will mean more to them.
Our jobs often call upon us to say "no." Unfortunately, that is not normally the most popular answer.
In my experience, most people don't care exactly how they reach the goal; they only care that they reach it. The challenge then becomes how to structure your argument.
I have often found the most effective way to explain why a particular approach should not be followed is to 1) provide a reasonable alternative that accomplishes the same goal; and 2) explain how the alternative benefits those you wish to persuade. (This last element is somewhat similar to the advice offered by Deanna Miller.)
I wish you luck.