Possible bug: Internal rounding of values is inconsistent

1

I’ve searched the forum for rounding issues, and found topics that address the discrepancies that sometimes exist between suppliers’ invoices and Manager’s internal math. This post isn’t about those issues; this is about a rounding inconsistency that exists solely within Manager.

The issue:

  • When editing a Purchase Invoice, the displayed total is the sum of all unrounded individual line items.
  • When viewing a Purchase Invoice, the displayed total is the sum of all rounded individual line items.

Edit: This issue applies to Receipts & Payments (and perhaps other places) too.

This issue results in situations where the viewed (and recorded) total does not equal the rounded result of the entered (and anticipated) total. For example:

edit
view

Or, in other words: round(200.1318, 2) != 200.12

In my (admittedly limited) experience, it seems like the majority of supplier’s invoices sum all unrounded line item totals into a grand total that only then is rounded down to two decimal places (like Manager’s edit mode total, and unlike Manager’s view mode total).

In any case, implementation details and/or backwards compatibility issue aside, I think these two internal calculations should probably be consistent with each other.

In workflow terms: Occasionally, while entering a Purchase Invoice, the total is previewed correctly, matching the supplier’s invoice, but it then ends up being incorrect once the entry has been saved. The invoice then needs to be (sometimes laboriously or confusingly) re-edited to artificially correct for the inconsistency.

Best,
Dan

2

The view mode displays the output that potentially goes external to the business. If the view total was to be the rounded edit total then the 2 decimal place rounded final output would have an error in the math.

Rounding the “Amount” on each individual line in the edit mode would remedy this, but would not remedy occasionally having to re-edit a Purchase Invoice to exactly match the supplier’s amounts.

3

The behavior you describe is necessary for two reasons:

  • To ensure line-item calculations are correct, including individual tax calculations. The entry total reflects what has been entered and is exact.
  • To ensure all fields in the finished View can be represented by available currency divisions, including totals.
4

Thanks @AJD and @Tut for your explanations of this behavior. I understand.

However, a preview of the rounded view (external) total should be displayed responsively somewhere within the edit interface, either in place of the current (exact, yes, but somewhat meaningless) total, or somewhere nearby.

Rounding each line and summing them is non-trivial to estimate, especially when there are many lines, and it often takes me more than one attempt to get the final (view) total to match. This back-and-forth “game” is a frustrating waste of time and energy when the value could be easily calculated and displayed in real time.

Something like the following, but perhaps using different terminology or layout:

totals
totals670×501 16.4 KB

5

@Brucanna, thanks for noticing and fixing my typo!

6

My comments were not very clear about rounding each line in the edit mode. They implied that each line be edited manually to a rounded amount. What I meant was that the system should round to 2 decimal places at line level and the total would then be a sum of these rounded amounts. However, this may not always result in matching a Supplier’s invoice exactly, which would require a re-edit of perhaps one or two lines.

7

This is currently exactly how the view mode calculation works, but not the edit mode, which does no rounding whatsoever.

8

You’re correct @loglow.

9

Want to add to this.
.
Where I live sales tax is 7.5%. I use tax included on my sales receipts. I charge $27 for an item, with tax it comes out to exactly $29.025. If I have multiple different items at the 29.025 price with tax in a single receipt, lets say 2 different items, the total in the edit mode will show the expected outcome of 58.05. Once I hit create, the statement is changed to show 58.06, and it increase for ever different item.

When money is calculated in real life, the total is rounded, not the individual items. The workaround is to change the price to 29.0249.

If I have 2 of the same item at 29.025 (quantity 2) the price is correctly show in both edit and view.

I did not notice this until recently, so going back to change the last few years of sales to have the correct totals has been and will continue to be a pain.

Whether this is a bug or not, the numbers should be consistent so that we don’t have to edit the entry every time they are wrong. I could show a screenshot, but honestly this is east to replicate. I will if needed add screenshots.

10

That depends on the accounting system in use. Most computer-based systems calculate tax line by line, round to the nearest subdivision of the currency involved, then add line items. That is the only way to make the total match the sum of line item amounts displayed. Most manual systems operate the other way, adding all tax-exclusive prices first, then calculating tax. Both methods are acceptable to tax authorities. So you should not worry about this. There is no reason to go back and change prior transactions.

Your example does not make sense, though. You said you are charging $27.00 on a tax-included basis. But your numbers align with tax-exclusive pricing. See https://www.manager.io/guides/9502. Further, you say that if you enter $29.025 as a tax-inclusive price, the total for 2 units comes to $58.06. But that does not happen. The finished transaction shows the same $58.05 as the Edit screen. Actually, the difference occurs with the single item, which is rounded to $29.03, because you cannot charge anyone a fraction of penny.

They are not wrong. They are simply the result of a different approach to calculation than what you thought was happening. All amounts are shown in whole pennies. And all totals equal the sum of amounts, not the sum of unit prices.

11

What I said was we charge 27, with tax it is 29.025. Therefore I use 29.025 when I input the price with tax inclusive. I literally said this… and I just noticed you misread my other line where I said adding 2 units comes out to 58.05 (not 58.06 as you claim I said).

The numbers are coming out wrong if they are not the same. If 2 + 2 is showing as 4 on the calculator, and you write 5 down elsewhere, the numbers do not match. What I am saying is they should match, regardless of the answer. If they match, we can work around the problem.

As for the method of calculating the tax, for tax purposes sales tax in FL is calculated by taking gross taxable sales for the month and multiplying by 0.075 (6% FL and 1.5% county). So when Manager shows I collected $500 and I owe $550 (I am exaggerating the difference to make the point), there is a problem.

The purpose of using a program to track finances is that you can expect the results to match. Perhaps there should be an option to calculate line by line vrs subtotal. Regardless the numbers should match when doing accounting.

I understand that there a two ways to approach the summation of numbers, I have only ever experienced subtotaling before tax, which is how tax is paid in FL. It is also how tax is calculated at every retail store I have ever purchased anything in.

I can continue to work around this, but I was coming onto the forum to say my piece after another annoying night of number entry where the math doesn’t add up to the expected value and found another who had the same issue. Side note, Square (major card processing company) calculates tax on the total, not by line. This is why I even have an issue, Square is collecting a specific amount of money, and the numbers are not the same when I enter them.

After posting this I don’t even know how to continue, it feels like you didn’t read my post since most of your response is misquoting or misunderstanding the words I wrote. I am not trying to be hostile, but I do feel most of the time you are hasty to attack posters. I get that there are a lot of people who try to make suggestions and it can be difficult or annoying, but please remember most of us (I hope most of us) don’t like to use our already limited time posting on here unless the subject has caused us enough grief to warrant a post.

12

No, I did not misread your line. You wrote:

Manager matches using the numbers on the viewed transaction, not some number you calculate separately on a calculator.

The difference will not be that big. You are making a problem where none exists. Besides, if the state wants you to calculate the tax to remit by multiplying gross sales by 7.5%, go ahead and do so. The state never sees your Manager accounts.

That may be true in the stores you have been in. But it is definitely not true elsewhere, because most accounting packages do not work that way. The odds are good you just have not noticed, because very few accounting packages will show unit prices in increments smaller than a penny (or whatever is the smallest increment of the local currency).

Actually, I read your entire post several times because it was confusing and your example did not match what you wrote. I even created a new test company to duplicate your example since you were unwilling to post screen shots. That test case contradicted your claim. I’m sorry you think I attack posters. Very frequently, they misrepresent what the program does and provide inadequate information to diagnose their problems.

13

To clarify something, I misread your quote. I was trying to say, if you have two different items at 29.025 each it adds to 58.06 in the view screen, but 58.05 in the edit screen. However, if there are two of the same inventory items (quantity 2) then it adds to 58.05 in both screens. This is true, and remains how Manager is calculating items. I separated the examples in my first post in an attempt to not confuse.

This is accounting, being off by $.01 every time is the equivalent to $500. Accounting is not supposed to be about getting close enough, it is supposed to be accurate every time.

Manager presents 2 different answers in 2 different locations. It does not matter where the calculation is done, they are presenting as different. You seem to have the idea of how it calculates as being the problem, its the presentation of 2 different sets of values that is a problem.

Not only in the fact that having 2 numbers for the same basic summation/multiplication literally means one of the numbers is incorrect, but the value you are create in the transaction is not the one that is added in the ledger.

I am not making a problem where none exists, I am making an actual problem larger then it is. Telling me to go ahead and do the math separate from the accounting software in order to track accurate numbers is being dismissive.

You are right about the stores I have been in, they are all in America. Lets not pretend there is not a decent number of American users, so why can’t there be an option for areas of the world that use the other method? The other accounting packages I have used are Quickbooks online and desktop. Admittedly, I never encountered this error; though to be fair I did not have a number that rounds odd at the time.

I did not say I was unwilling to submit screenshots, I am not able to tonight which is why I stated I would do so if required.

Yes, even in this response you present as extremely hostile, rather then making sure we are communicating. “You are making a problem where none exists” This assumes my entire post is wrong. I have tested this problem and have been dealing with it ever since I changed my prices to $27. At most other numbers the tax rounds correctly.

This program is, to the best of my knowledge, an accounting program. The way I define the area of accounting is: accurate recording and tracking of currency. Again, I understand how the program is arriving at the numbers, the problem is in the presentation of two different values. It is the same thing the OP was trying to convey, but like my posts, has turned into a debate on whether the math is being calculated incorrectly. It is not. It is different then we are used to. The presentation of the values is the problem.

My point about 2 +2 = 4 or 5 was not about the math being wrong. The equation presented the correct answer, the observer recorded a different answer. That is the problem, the answer should be the same in both cases (view mode vrs edit mode).

14

Since I’m the OP, and because the updates to this thread hit my inbox, I felt like chiming in…

First of all, for the benefit of @Jeff_Kesling, my understanding from past conversations is that @Tut is not an official customer support representative for Manager. Tut is just a very active volunteer member of this forum, and also (I believe) a moderator here. In that sense, I do see Tut as Manager’s de facto customer support, since no other practical support options for Manager exist.

As someone who was initially very impressed by the design, presentation, and functionality of Manager, I have to say that I no longer use it. The primary reason does, in fact, come down to support. The business/licensing model employed by Manager is somewhat interesting, and is arguably generous in certain respects, but at the end of the day it simply doesn’t suit my needs.

If Manager were open-source, I could tweak it, submit pull requests, or hire someone to fix bugs or implement new features. That would also foster a large volunteer support community, consisting of numerous users with Tut’s degree of participation. Likewise, if Manager had a dedicated support team for paying customers, that might accomplish many of the same goals. Unfortunately, Manager is neither of these things. Manager is closed-source commercial software without any official support, and unfortunately for me, that’s a dealbreaker.

In any case, I hope this particular issue does end up being resolved in an accurate and elegant way.

All the best,
Dan

15

Yes, but the behavior is still consistent across the program. The tax calculations and account posting are both done on a line-item basis. When looking at the Edit screen, the tax calculations for your tax-inclusive prices are not represented. When looking at the View screen, they are. When you have one line item for two units at $29.025 each, the calculation comes out evenly, and the amount for that line item can be presented as $58.05. But when you have two different items, the two calculations must both be rounded to the nearest penny, so the completed transaction shows two lines at $29.03 each, which adds to $86.06. As I said previously, the total on the transaction has to match the sum of amounts, which are rounded to the penny, not the sum of unit prices.

I guess I did not express myself well enough when I said the problem was not that big (and related things). What I have trying to convey from the beginning is that Manager, like all accounting or cash register programs, is constrained to showing extended pricing in units of currency that are in circulation. In your case, this means everything must be to the penny. You simply cannot execute or record a transaction in fractions of a cent, no matter what your inputs are. As an example, go to your local grocery store. The price tags on shelves probably display unit prices on everything, such as 7.509¢ per ounce. Buy a 32 oz. container, go through checkout, and you will be charged either $2.40 or $2.41 (depending on how the grocer’s system is programmed), not $2.40288. In most situations, the roundings will tend to cancel out over time, or nearly so. But if everything you sell costs the same, the differences will indeed accumulate. The important thing to understand is that the program is consistent, whether it behaves the way you think or not.

No, it does not. What you are interpreting as two different answers are actually the inputs to and outputs from a calculation and display process. The Edit screen shows inputs. The View screen shows outputs, constrained as I described above by the realities of your currency. You are bothered by differences of fractions of a penny. Consider how you would feel in one of many countries where small currency denominations have been removed from circulation. In Sweden, for example, all öre coins were discontinued in 2010. Goods are still priced in öre, but when paying with cash all sums are rounded to the nearest Krona. Yet Manager still displays öre, because electronic transactions might use them. In some other cases, though, Manager will actually not display deprecated denominations. Your situation is quite benign compared to those.

Because, the program must preserve the possibility for reversing only one line item on a transaction, or even part of a line item. The customer buys 3 of A and 6 of B, then returns 1 of A. The tax calculations for B cannot be mixed up with A’s.

I did not suggest you do this. I said that, if your state tax filing process requires you to calculate a remittance by multiplying gross sales by the tax rate, do that. Financial record keeping and tax filing are two separate things.

Those remarks are true.

16

Then you are entering the tax inclusive price wrong.
If the manually calculate price is 29.025, then you either enter the per unit price as 29.02 or 29.03 as your customer can’t pay 0.005 if they only purchased one unit. Just because your example is based on two units, it just hides the incorrectness of your price entry. What if your customer purchased 3 or 5, does that change form a customer who purchased 2 or 4.

Prices are always entered as payable on a per unit of sale basis, so the question is - can your customer pay you 29.025 if they only purchased one.

Yes, but you can only expect that result if the “user” has enter the data correctly.
A programme can’t reinterpret what a user as put in incorrectly.

As an aside, the original posts in this topic were regarding rounding with regards to suppliers/purchases whereas the later posts are about rounding with regards to customer/sales which are two separate matters.

17

As far as using the tax inclusive price wrong comment. If you used either 29.02 or 29.03 they would make the transaction display incorrectly depending upon quantity. I live in the USA, when we calculate taxes it is based on the total of the entire transaction. There is no option to calculate tax in this way in Manager. My use of 29.025 is an attempted workaround, but it fails as a workaround due to the same issue repeated.

The only way I have found to reduce the inconsistencies has been when I did not update all my inventory item prices (some were 29.025 and others were 29.03) in which the randomness of a customers purchase reduced the likelihood of encountering the rounding issue.

All I am asking for is the ability to set tax calculation based on total (or subtotal) instead of calculated on a per item type basis.

The user is not incorrectly imputing the data, the user is calculating tax differently then the program. If the calculation were only on my end, I could simply ignore the error (as stated by Tut, IRS allows some error), but I am pulling my numbers from Square and they are different about 75% of the time (by +/-1 to 4 cents). This requires going back into the transaction and changing values (29.025 changed to 29.03 or 29.03 changed to 29.025 depending on final value).

18

This is not true. Almost every accounting program on the market calculates tax on a line item basis and adds it up. Depending on what state you are in, you may be able to look at something as simple as a grocery receipt to see different tax rates applied on different foods, others applied on non-grocery items, etc. Now, is it legal to compute a subtotal and apply a tax rate to it, assuming everything is taxed at the same rate? Yes, and that’s how most manual systems work. But the methodology is according to the design of the system and has nothing to do with our being in the USA.

This would make it impossible to properly return individual items from a multi-item sale or purchase. (That was explained before.) You need to accept that Manager is not going to change to accommodate your particular desire. The line-item basis of tax calculations is too deeply embedded in the system. If, as a result, the program doesn’t meet your needs, you should choose another one (if you can find one that works that way).