185
Good morning,
A third party application we are considering using would, in some occasion, create negative debit or credit amounts in the AP and GL modules.
Would this cause an eventual problem in Dynamics GP (or FrX) ? Intial testing have shown that it does not, but we would like some confirmation from other Dynamics GP users.
Thank you for any information,
Michel
*This post is locked for comments
What we have here is a difference in North America vs. the rest of the world. Having worked with European accounting software, negative debits and credits are common. I belive it is called "Red Sterno" marking. It is a generally accepted accounting practice outside of North America. Our Axapta and Navision cousins could probably had more about this being a common practice.
I actually have an integration running at a customer that does negative debits to cash (via bank transactions). Works fine, no reporting issues.
But as always if your are doing something that the developers did not anticipate, TEST.
Warren
I will have to disagree with some people who think that posting a negative number is a bad practice or 'bug' of another software package. Being more than twenty years in accounting I can assure you that this is actually the correct handling of reversals.
The reason is more or less simple (some exceptions, on some accounts exist though). I also agree that in some cases this cannot be done, but usually in that case we do the reversal of changed sides as an invoiced transaction, not merely as reversal (example: debit A 100$ /credit B 100$ and then we understood that we should have debited another account, X, so instead of reversal we have another corrective transaction, doing debit X 100$ /credit A 100$)
Let's take a simple example: the Cash (asset side).
You have a deposit of cash from a customer to his savings account, so you post Debit 100$ as cash banknotes and 100$ to customer's account. Then, oops, the teller sees that actually these were 120$ (silly, but just follow the logic here). So, cancels the receipt and his invoice, and proceeds to a reversal (sort of understanding the logic: value date = today for all transactions, USD is the local currency, denomination not important, transaction code not important)
So he posts: Cash Debit -100$ and Credit -100$ to customers account, writing REVERSAL and keeps the canceled invoice and the false customer receipt attached to the reversal transaction's posting receipt (*all* copies should be found in audit). Then, he posts the correct amounts, being Cash debit 100$ and Customer account credit 100$.
Now, before you ask why in G's name is that different from posting a REVERSAL in Cash as credit 100$ and debit customer's account with 100$, I am replying: because of the transaction log.
The teller's book should actually MATCH EXACTLY with the actions of the teller. So if at the end of the day we do it the wrong way, we will have
Cash debits total 220 (100+120) and credits 100.
and this is NOT matching the transactions, but just the total. Our teller (if he's a professional one) would absolutely complain and say that this is showing him like cooking. The same thing happens on the other side: the customer will see a deposit 100, then a withdrawal 100 (description as reversal), and then a deposit 120. Again, the net result is ok, but the handling is poor.
Finally, let's see the log of the correct operation. Again, the net result is the same, *but*, this time the teller is printing the log and agrees not only on the total but also at the debits:
Cash debits total 120 and credits 0.
Now, everything agree, and also the customer will see 100$ as deposit on the credit side, then again a minus 100$ description as reversal and finally a 120$ deposit - and *NO* withdrawals. If he's keeping all his receipts, he should have only one receipt of 120 deposit and this should match what's happen (he did NOT deposit 100, then withdrawed 100, and then deposit 120 - he only deposit 120).
I hope I made myself clear. I do not argue that the end result of a chenged-side reversal would be different in the total, I am ust saying that this is not the correct way of doing this. A final note: some accounts, by accounting definition, should *never* be debited (or others, never credited). How would you then make a reversal by using changed side?
Finally, I don't see where is this messing with reporting. The per day report is ok, both per transaction and on total, and same goes for monthly report. Again, this is not always the case as some accounts cannot (not by software but by the law) be debited or some others credited, and this is where another transaction is used (correction and not reversal - particularly when the use (the accounting year) has been closed).
Thank you for the hospitality
Nick M.
That was more the point of my comment. If the values are being stored negatively at the database level, then you for sure have a problem.
Actually GP supports negative debits and credits natively in the interface. If you key a negative debit GP will automatically move it to the credit line and vice versa. If the 3rd party is creating these negatives in AP and GL prior to posting and the normal GP posting routine are used I wouldn't worry about it at all. If the 3rd party is pushing posted transactions into GP then I would be more worried about potential reporting and financial statement impacts down the road.
Mark
The nature of GP is to support positive amount values in the debit and credit columns. Having a negative amount may indeed have undesirable effects on your financial statements.
If the developers of this 3rd party app where too lazy to evaluate a dollar amount and place it in the correct debit/credit bucket rather than allowing an unsupported negative to pass into the general ledger, I would recommend against the 3rd party app. Before purchasing, I would ask them to fix the issue.
But, to respond directy to the issue, I've seen some of these negative debits/credits in the past, and have not heard of any issues. However, if you call Microsoft with any issue related to them, they will not be able to assist you. That's a pretty big negative.
Ron Draganowski
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,214
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (