A shocking number of people who work with software that handles money are just winging it. I worked on a project once that handled payment processing functionality for other products at the company (it was a B2B SaaS where clients could take payments through our software). We also handled payments related billing, since the clients would owe fees to us and to our payments gateway for their transactions.
The payments gateway we worked with calculated their fees to a thousandth of a cent, but of course we could only bill whole cents. So basically every billing period there would be a < $0.01 balance due that carried over to the next bill, and every so often the carryover would add up to a full cent that needed to be charged. When we implemented our MVP we (engineering) explained this to the product and business teams, and it blew their minds. Our suggestion was to have a tooltip on the 1 cent charge with a link to a help article explaining how the accounting worked, but they were strongly against it and had us list the 1 cent as something like "other fees" with no explanation. They seemed convinced it was a thing that would happen only rarely, even as we were telling them otherwise. Anyway, that 1 cent charge just infuriated clients for some reason, and every month or two we'd get bug reports about it or requests to explain why it kept showing up. Fun times...
Because the bill included a detailed breakdown of all the fees by type and transaction. Typically our clients were charged a fixed monthly fee, a fixed authorization fee charged every time a payment was attempted (even if it was declined), and a fee applied to successful payments that was a percentage of the payment amount. There were other fees for things like processing chargebacks, but IIRC they were the same for everyone.
> If the month's charges were 406.783228 and I get a bill for 406.79 then that seems perfectly good.
Yeah, we definitely weren't allowed to round up and keep the change. I can't claim to know all the details involved but I suspect that doing so would've at least violated our contract with the payments gateway. Might've actually been illegal.
> If I get a bill that says 406.78, plus a separate 0.01, that's weird.
That's not how it worked. For the sake of simplicity let's assume that your activity is always the same, therefore you have new charges totaling exactly $406.783228 every month.
* Month 1: You owe $406.783228, your bill is $406.78, a balance of $0.003228 rolls over.
* Month 2: You owe $406.786456, your bill is $406.78, a balance of $0.006456 rolls over.
* Month 3: You owe $406.789684, your bill is $406.78, a balance of $0.009684 rolls over.
* Month 4: You owe $406.792912, your bill is $406.79, there's a $0.01 "other fee" line item on the bill, and a balance of $0.002912 rolls over.
It's unlikely that it would be illegal, or violate the contract with the payments gateway, if you charged the customer 406.78, and you made up the $0.003228 discrepancy so the gateway is paid off.
I wasn't talking about rounding up. I meant exactly the same thing you're saying about month 4.
> Because the bill included a detailed breakdown of all the fees by type and transaction.
Was it all rounded [down] to the nearest penny?
That type of bill can already fail to add up to the total very easily, like x.xx4 + x.xx4 + x.xx4. So I'm still not sure why there was a need to have a line item to explain this single penny.
Was there only a single charge on each bill that used fractional pennies? So that this was the only time that things wouldn't add up perfectly?
Canada abolished the penny some years ago. If some retail item in a store costs $2.03 and you insist on paying with cash, you will have to use a nickel and pay $2.05.
> Anyway, that 1 cent charge just infuriated clients for some reason, and every month or two we'd get bug reports about it or requests to explain why it kept showing up.
There is an obvious alternative here, which is to just absorb that fraction of cent, so the customer doesn't see it. Handling bug reports and infuriated clients costs more.
You could even just round up to the penny and ding the customer; if there is a 0.3 cent fraction coming from the payments gateway, turn it into a customer-facing penny, thereby collecting an extra 0.7 cents.
That way, too, there would almost certainly be zero complaints and bug reports.
If the customer is supposed to pay $103.45395 every month, you could turn it into $103.46, pocketing an extra $0.00605, or into $103.45, where you're out $0.00395.
Think about it; when you eat at a restaurant, often the prices for a meal are round like $11.50, even though the restaurants expenses are down to the penny. Why is that? Because they arbitrarily set the price. They don't say, oh, our ground beef supplier charges to the penny penny, so lunch will have to be $11.57.
Oh, the business teams found the approach puzzling---but what do they know, right? If they were smart, they would be software engineers.
> Oh, the business teams found the approach puzzling---but what do they know, right? If they were smart, they would be software engineers.
Well in this case the business teams selected the 3rd party payments gateway that the company would work with, negotiated the contracts with them, and worked with the 3rd party to set up how the customers would be charged. They and/or the product team determined that we'd use the 3rd party system to handle the billing because building it in house wouldn't generate any new revenue. They weren't stupid, but they choose an approach to payments processing that was pretty low level (because it generated more revenue, of course), without anyone at the company having a good understanding of low level payment processing details. The engineers learned because we kind of had to, but three years into the project (when I left) business/product would still routinely struggle with the details.
So anyway, WRT to billing, the task handed to engineering was: pull the billing detail from the 3rd party's API and assemble it into a statement that can be handed to a client. We had zero control over how the charges were generated or applying any rounding to the total.
If someone had a gun to my head saying, don't hide the sub-penny slices from the billing, I would just do the billing in thousandths of a cent, rather than make "leap cents" appear every couple of bills:
Amount owing: $123.45678
Please pay one of: $123.46 (a credit of $0.00322 will be applied)
$123.45 (a balance of $0.00678 will carry forward)
On the next statement, if they paid $123.46:
Previous balance: ( $0.00322) [credit]
New charges: 123.45678 { here we have a detailed breakdown }
Amount owing: 123.45356
Please pay one of: $123.46 (a credit of $0.00644 will be applied)
$123.45 (a balance of $0.00356 will carry forward)
etc.
That's literally "put the billing detail from the 3rd party API and assemble it into a statement". Since the billing detail from the 3rd party API is in thousandths of a cent, then that implies the statement must have thousandths of a cent.
If the two payment options were determined to be too confusing, one of the two could be dropped.
I think that's a case for just dropping that cent. As long as it's your own money and not tax you're underreporting it's not a problem as long as it's consistent.
Carrying the remainder microcents as a bill seems overkill and not necessarily correct. Accounting regulations and accepted practices have well established rules on rounding, like bankers rounding (1).
You could probably treat the extra microcents as being on the next pay period. Though that's annoying as if I close an account I'd expect it to be paid in full, not a few microcents remaining.
The payments gateway we worked with calculated their fees to a thousandth of a cent, but of course we could only bill whole cents. So basically every billing period there would be a < $0.01 balance due that carried over to the next bill, and every so often the carryover would add up to a full cent that needed to be charged. When we implemented our MVP we (engineering) explained this to the product and business teams, and it blew their minds. Our suggestion was to have a tooltip on the 1 cent charge with a link to a help article explaining how the accounting worked, but they were strongly against it and had us list the 1 cent as something like "other fees" with no explanation. They seemed convinced it was a thing that would happen only rarely, even as we were telling them otherwise. Anyway, that 1 cent charge just infuriated clients for some reason, and every month or two we'd get bug reports about it or requests to explain why it kept showing up. Fun times...