rounding to 2 decimal places in accounting software is causing difference in totals

Question

I am developing an accounting system where another system sends data to my accounting software. the other system uses double-precision while my accounting system uses decimal with rounding up to 2 decimal places. the problem occurs after the rounding is done, the totals representing the debit side and credit side are not equal anymore due to differences around 0.01 or 0.02...or so due to the rounding.

This makes it impossible to save the voucher to update accounts. I am wondering what could be a professional solution to that problem.

Any help is appreciated as this issue is occurring in production.

Answer 1

I searched the Internet for what others have said and done about this topic and can also describe what the software that I built does.

The problem is that the input data has higher precision (more decimal digits) than the target system, which means that each number has to be rounded. However, the sums of rounded numbers from each side (debit or credit) have to add up to the same total number, which should be the same as the rounded total from one side (debit or credit) from the other system, so that the imported transaction total is the same as the input transaction total when rounded.

Solution 1 (found it on the Oracle site):

They call it "soft rounding". For a series of numbers, take the first number and round it. Use that round number for the output. Then take the difference between the precise number and the rounded number, and add that to the next number. Then round that, use it as your second output number, and calculate again the difference and add it down. At the end you will have some leftover that you add to the last number. At that point in your case you should modify the last number so that the total of all output numbers matches the desired total (which was the rounded total from the input). Do the same for the other side (i.e. credit or debit).

Solution 2 (another software package):

They create a "system" account in the chart of accounts specifically for rounding. Do your rounding, then post the difference between the debit and credit to that account and add it to the transaction. That will accumulate all rounding errors into that rounding account, and hopefully they will mostly cancel out. From time to time a posting is done to zero out the rounding account and add it to income or expense, I guess.

Solution 3 (done in the software I built):

This problem is discussed in Theory of Apportionment (see Wiki, how a whole number of US Congress seats are allocated to US states based on population). In our software we round and add. Then we sum the rounded numbers and find out how many cents we are off from the desired total we started with. We then order the amounts by largest first and start adding or subtracting one or more cents to each number down the list until we apportion the entire excess.

By the way, "banker's", or even-number rounding is recommended, where you round the number 5 not always up but always towards the nearest even number.