While trying to re-create @RyanZim’s rounding issue, I noticed other odd behavior regarding the way Manager handles minutes vs. fractional hours in the Billable Time module.
If you make a Billable Time entry for 20 minutes, that entry is correctly calculated at 1/3 of an hour. If the rate is $15/hour, then an entry for 7 hours and 20 minutes shows up as costing 7-1/3 x $15 = $110. This $110 appears consistently throughout in all the places it ought to:
Once an invoice is generated for this Billable Time, however, the 7 hours and 20 minutes is suddenly treated not as 7-1/3 hours, but instead as 7.33 hours, truncated at the hundredths place. Instead of $110, it becomes 7.33 x $15 = $109.95. The customer is invoiced only $109.95, and most of the places that said $110.00 before the invoice was issued are suddenly changed to $109.95:
The original Billable Time entry keeps its amount of $110.00, but the revenue account (originally called Billable time – invoiced but renamed here to Hourly services) shows $109.95:
A look at the General Ledger Transactions report reveals where the missing nickel has gone. An automatic Write-off entry is created by Manager to balance the Billable time account to the Billable time - uninvoiced (originally Billable time - movement) account:
I understand why monetary entries should be rounded or truncated to hundredths (or to whatever the local minor currency unit is) with the rounding errors written off, but the inconsistent handling of fractional hours makes no sense to me. If a customer’s account shows that he owed me $110 before the invoice is generated, then he shouldn’t owe me $109.95 after the invoice is generated. The minutes should be treated consistently across the application. It can be as minutes, unrounded fractional hours, or rounded decimal hours, or whatever – but it ought to be consistent.
This appears to have been discussed here previously, but the inconsistent behaviour was never corrected, other than applying the automatic write-off.
I remember this issue being brought up before and I thought I fixed this actually.
The solution was that when amounts on Billable Time are calculated, they should be calculated by the same formula they would be eventually calculated on invoice.
So billable time of 7h 20m should be internally treated as 7.33 and the amount on billable time should come to $109.95. This would prevent discrepancy during invoice creation.
If you want to avoid this problem altogether, avoid recording 1/3 of an hour as 1/3 is difficult to express in decimals.
This is not new problem. For long time, I’ve seen many businesses either charging by 15 minute units or by 6 minute units. Whatever unit you choose, it should be divisible by 3 so 3,6,9,12,15 etc. are all fine.
20 is not divisible by 3 without reminder and that’s causing the mismatch here.
But they are not. See the example I posted above, and notice how the $110.00 balance changes to $109.95: The 20-minute increment is treated as exactly 1/3 hour (and $15.00) before it’s posted to an invoice, and as exactly 0.33 hour (and $14.95) once it’s posted to an invoice.
Beyond that, I strongly disagree that a business should need to abandon 20-minute billing increments to conform to a piece of software. Rounding errors are unavoidable, but this problem is not. Hours and minutes should be tracked and added up as hours and minutes (so three 20-minutes increments should come to 1 hour, and not to 0.99 hours). Once time is converted into money, THEN and only then should rounding occur – and it should occur only in the currency amount, not in the time amount.
Wrong way:
20 min + 20 min + 20 min + 20 min = 0.33 hr + 0.33 hr + 0.33 hr + 0.33 hr = 1.32 hr = $133.32 at $101/hr.
Right way:
20 min + 20 min + 20 min + 20 min = 80 min = 1.3333333… hr = $134.666666… at $101/hr, rounded to $134.67.
(I think it’s fine to display 80 minutes as 1.33 hours on an invoice, but the math should be done on the full-precision equivalent of 80 minutes, i.e. 1.333333… hours.)
Even if you disagree with me on the way fractional hours should be handled, surely you see that the money amounts shouldn’t change magically when the invoice is created. If the invoice is going to be for $109.95 in the initial example, then the amount really should never be displayed as $110.00 – which it currently is. I happen to believe strongly that it should always show up as $110.00 because 20 minutes is 20/60 hours and not 0.33 hours, but even if we disagree on that, the calculation method should be consistent over time.)
This is not about software. This is fundamental mathematical property of decimals not being able to easily express 1/3.
There is a reason imperial system is still popular in USA. What’s 1/3 of foot? Easy… it’s 4 inches. How about 1/3 of meter? 33.33333… cm.
You see, this problem goes beyond software.
20-minutes being 1/3 of an hour is problematic to express in decimals. That’s why every business in the world should avoid billing in increments which are not divisible by 3. For this reason, most businesses use either 6 minute or 15 minute billing increments. This has been common practice long before there were even computers.
I do agree that billable time module should work with the same amounts as sales invoices. I will fix that inconsistency (I thought I already did) but it doesn’t change the fact that 20-minute billing increments should never be used.
Why not just handle everything internally in minutes and be done with the problem altogether?
1 hour 20 minutes at $101/hour can be handled internally as 80 minutes at $1.68333333/minute (using floating-point math). You get $134.666666…, rounded to $134.67, which is the right answer. You still show it as 1.33 hours in the Qty column of the invoice and as $101/hr in the Rate column, but the calculation is done in minutes and the Total is correct at $134.67.
If invoice shows quantity 1.33, you expect line total to equal quantity * unit price regardless of what account is the amount posted to.
Otherwise how would that work?
You sell 1.33 quantity on two invoice line items. On first one, you sell billable time, on the second one you sell 1.33 of inventory item. The same quantity, the same unit price but different totals only because one is charging for billable time and the other is selling inventory? That would be bad.
Okay, we disagree on that. I consider time to be a special case. When I see 1.33 hours, my mind converts it to 1 hour 20 minutes, and I would expect to see one-and-a-third of the hourly rate. When I see 1.33 kg, my mind doesn’t convert it because a third of a kilo isn’t a thing, so I would expect to see exactly 1.33 times the per-kilo price. On the other hand, if I see 0.33 feet of fabric, my mind converts it to 4 inches, and I would expect to pay a third of the per-foot price.
Maybe you’re too young for this, but think about pre-decimal money. If you bought 40 candy bars at 4 pence each, you paid 13 shillings, 4 pence. You didn’t pay 13 shillings, 2 pence – even though 4 pence might be rounded to 0.33 shillings, which times 40 is 13.2 shillings, which is 13 shillings, 2.4 pence.
Things that are non-decimal (like hours and feet) should be handled differently from things that are decimal (like modern money) or unitary (like inventory items).
I’ve started trying the Desktop version of manager.io and am experiencing this same anomaly with billable time. I agree it’s annoying. However, it looks like it’s not so easy for the developer to remedy.
The only way I have found to workaround this is to Edit the invoice and increase the number of decimal places. e.g. if I work 40 minutes, this is a decimal-based time of 0.666…recurring, whereas manager.io will only go to 2 decimal places (ie 0.67). This causes an incorrect invoice amount. I edit it, and change it to 0.6667. This is enough to make the invoice display the correct amount. Unsure whether or not this causes issues elsewhere.
I agree with you though that the software should keep the figures as time rather than converting to decimals, but sounds like it’s easier said than done unfortunately.
This was never fixed. I’ve just finished hunting down a error in a customer’s account that accumulated to tens of dollars over a few years, because of numerous 40-minute sessions that resulted in accumulated “write-on” entries in the ledger caused by 40 minutes of Billable Time entries being converted internally to 0.67 hours (instead of 0.666666… hours) before being added together instead of after being added together.
@Lubos, you mentioned above that you wanted there to be consistency in time units across the application, but the inconsistency persists. Billable Time forms accept times in integral hours and minutes:
Running, pre-invoicing balances reflect amounts calculated in minutes, so three 40-minute sessions at $100 are shown in running customer balances as 3 x 40/60 x $100 = 3 x $66.67 = $200.01:
Once the invoice is created, however, amounts are re-calculated based on 0.01-hour increments, so that same $200 balance is invoiced as 3 x 0.67 x $100 = 3 x $67.00 = $201, and $0.99 “Write-On” entries are created in the ledger:
I still argue that the user should be able to configure the time-keeping units for his business, be it fractional hours (rounded to hundredths) or integer hours/minutes, and all calculations and entry forms should respect that choice. But we’ve disagreed on that, so at least let the program reflect the built-in choice of 0.01-hour intervals on all entry forms, including the Billable Time form. If you’re not going to support 40-minute entries, then at least show me that on the entry form by making me enter it as 0.67 hours and calculating it as such from beginning to end.
(I’ll make one more appeal to you to respect the user’s choice whether to use minutes or fractional hours. Say my business takes on micro-tasks that are measured in minutes. Why can’t I bill for exactly 1 minute, rather than 0.0167 hours rounded to 0.02 hours? Why should I have to change my practice to bill in 36-second (=0.01-hour) intervals?)
