Inconsistencies in G/L Entry Table


I’ve recently stumbled into what I think is a rounding error behind the scenes (from what I’ve read, the majority of these errors are because of a rounding differences in one way or another). Here’s the situation (we’re in NAV 2013 BTW).

This is a sales order in USD currency (LCY is CAD). This order has a 80% prepayment on it that was posted on July 25. Now it’s time to post the final invoice so that we can ship and get the final payment but when I post it I get the “The transaction cannot be completed because it will cause inconsistencies in the G/L Entry table.” error message. I have discovered that if I post the final invoice on the same day as the prepayment invoice then it works properly. I then realized it was probably something to do with exchange rates (when changing the posting date I had clicked YES to update the exchange rate) so I tried posting with today’s date but overriding the FOREX rate to be the same as it was on the prepayment - that works as well.

So, how do I go about fixing this? I could keep the same FOREX rate and do a manual GenJnl to do the exchange gains/losses (for this order we’re looking at about $2,000 of a gain). But that seems kludgy.

I thought that maybe changing our rounding precision to .001 would fix this - but I can’t figure out exactly where I should change this precision … there are many places and I’m not sure how they all work.

Any ideas?


An inconsistency error is always a programming error. And most of the times it’s due to some small customization no-one thought could have an impact.

So my first question is, did you have any of your posting codeunits (or related codeunits) customized? If yes, then have the developer debug it to find this error. If no customizations are done then it’s an error, then you should ask your developer/partner to report this error through the official channels to Microsoft. This way they will be able to create a fix for this.

Find and fixing these inconsistency errors are often both difficult and time consuming. If you want to understand a bit more about this error and how they can be found, then you should read this post in Søren’s blog.

Hi Erik,

Thanks for the quick response. The only codeunit that is modified in our database is the Format Address one (CU 365). All others are out-of-the box default ones.

I will contact our Partner to get this sorted out.


Hi Devin,

Yes do that. It’s important that such errors are being reported directly to Microsoft. Otherwise they may never know about the error.