Programming vs. Accounting - Rocky XII

No, I am not riding on the coattails of the recent release of Stallone's latest movie 'Creed' like I so unabashedly did with my blog on Star Wars and ERP Implementations.   I will make no references to Rocky Balboa or Apollo Creed here and I will not conjecture on who would be the better developer.  

With that said, programming solutions can conflict with accounting best practices and it can seem like a slugfest.   But should one always "program" oneself out of an accounting problem? 

Here's a common scenario.  A transaction in Microsoft Dynamics NAV was posted with an incorrect date.  A programming solution would be to go into the backend and correct the dates of all the related posted entries.  Yes, it should work- but should the problem be solved in that manner?  

From an accountants point of view, no.  There is no audit trail by going into the backend and changing data.  Additionally, it is risky even when one is confident of one's knowledge of the system involved.  

Moreover, the users of the system may become dependent on a programmer's ability to make a quick fix and request future data entry errors to be corrected in such a manner.  The correct way to solve this is to enter a correcting transaction to reverse out the original transaction and re-enter the new transaction.  

What if 1000 transactions were posted with incorrect posting dates and it will likely take two personnel a full week to reverse and correct the transactions?  In this case a programmer could come in handy, but how the problem is solved is key.  

One could write a process to change all the posting dates of all the transactions involved.  However, this has its risks depending on the system and transactions involved as it bypasses the normal validation of data.   One should instead write a process which creates the reversing and correcting transactions as if the user had entered them.  Thus a full audit trail is maintained.  The programming solution "simulates" a user entering the transactions by hand and therefore, follows best practice.  

There can be exceptions.  For instance, 1000 orders were posted with a Text field incorrectly populated.  It is 100% certain that the text field is not tied to any logic within the system and is purely informational.   In this case, a programming solution to update the posted data directly is of no real risk.

Judgement is required, then to determine when a programming solution should be undertaken or not.   In the majority of cases. if an issue can be solved by entering transactions, that will be the ideal solution.