Hacker News Reader

Comment by forinti | Hacker News Reader

I have a personal anecdote on this subject. A long time ago I worked at a bank and I had to calculate a large number of accounts regarding agricultural loans. These were state sponsored loans. When I finished my task (this was a Java job), I found that sometimes the results were off by $0.01. So I asked my boss how I should do the rounding, to which he replied that an error of up to $1 was acceptable. If I recall correctly, the amounts where in the hundreds and thousands.

View on HN

On my first day in a new company, not even senior dev yet, I met with the head accountant. I asked about her top problems, she said her top problem was that the application would produce different invoice on screen, different invoice when printed as PDF and a different invoice in the accounting software. About 1% of all invoices were affected but due to amount of billing they were doing (telecommunications and advertising) they needed to have 3 FTEs just to correct the invoices.

And correcting the invoices meant playing with numbers so that at least the PDF and accounting software agreed on the total value and tax.

She also said they had at least 2 different employees and an external company look at it and not able to fix it. She also told me not to bother because she does not believe the problem can be fixed (that's what she was told).

I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still.

I ran couple of experiments to reverse engineer how the accounting software did the calculations -- the exact order of them and the exact rounding rules. Then I built a small module that captured those calculations. Then I changed all doubles to arbitrary precision.

It took two days and the problem was fixed but it took couple more days before accounting department actually believed it.

> I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF).

That's actually kinda normal, in some industries.

For example, an amazon marketplace seller's warehouse management system might not be tightly integrated with Amazon's basket/checkout display logic.

In some situations the results of recalculating are supposed to be different. For example, if there's a "5% off when you buy 3 widgets" offer and you check out with 2 widgets in your basket, the offer doesn't apply. But if you checked out 3 widgets, thus getting the offer, then the seller found they were low on stock and could only send you 2, you should get the 5% discount on those 2.

> It took two days and the problem was fixed but it took couple more days before accounting department actually believed it.

Those 3 people that now didn't had a job probably weren't all that happy xD

if there ever was a reason to apply DRY at all cost, this is one

> I looked at the software, it had two separate copies of the invoice calculation (separate for on screen and for printing to PDF). And of course it would send the invoice to the accounting software which calculated the invoice in a different way still.

Your setup made it sound like something crazy and inane, like "the PDF printer used on those machines changed floating point rounding modes" or what have you.

In olden times we would "print to PDF" as in have a little piece of code to format the document that would be sent to a printer which could be a PDF document.

In this particular case we had two separate pieces of code, one running on the client (for on screen presentation) and one on the backend (to create the PDF on a shared location and produce a download URL).

There was the famous "Xerox photocopier changes digits sometimes" bug, but that's not what's happening here.

The hero I want to be

It is easy to be a hero when the company is shitty.

My career advice is to work in a field / company / job where you can be somewhere in the top 10-20% of all employees. Just don't overdo it, if you are top 1% you are probably aiming too low and could be working for better paying, more rewarding field / company / job.

For a lot of my career I was working for financial institutions like banks. A lot of really badly managed projects with definitely not top level developers. Easy to be a top performer. I really like helping people and projects and it was working well for me especially when it was easy for me to provide valuable help.

I got hired once for a really good company with really top performers and suddenly I lost the status that I was so used to. I was keeping up with my work, sure, but I was no longer a shiny star. I got back to working for banks.

Exactly. I think many people start overthinking things in banking. Most accounting/finance departments are ok with rounding pennies every month.

I run a Commercial Real Estate Servicing platform, where we are accruing interest on large balances daily. Our method is to not do the rounding daily, but add up all the numbers for a given period, say a month, and then round to the penny and create a single adjustment rounding transaction along with it. Accounting departments love us for it.

If we rounded daily before storing the amount, the adjustment for accounting is usually a few pennies at least every month they have to make. Our method, it's roughly $0.01 per year with monthly periods, adjusted usually at the very end. Which on a $20MM loan, is very well within the bounds of acceptable.

I love how small details, like rounding always up for 2.50 would be significantly skewing the numbers to the higher values, so there are functions like ROUND_HALF_EVEN that would round up on even numbers, and down on uneven ones.

Yeah. I worked on a lending platform that used floats (!!!), and their response when I brought this up was that as long as the result is within something like $10, it was not an issue.

I brought up specific math problems that floats couldn't handle and they weren't phased

The real reason is because Cathrine Zeta Jones and James Bond actually did implement a program in Malaysia that collects all those rounding errors on a seperate bank account. And since it wenr global, affecting everypne, everyone thinks it ia simply normal.

Or it is because rounding errors happen and accounting is a bitch. The first option makes for a better movie plot so.

I guess I’m old because I credit that plot to Superman III. TIL it’s called Salami Slicing https://en.wikipedia.org/wiki/Salami_slicing_tactics#

Man, you and I remember Office Space differently! /s

Whenever I input my tax data on forms, it always rounded to the nearest dollar. It was strange that accuracy didn't seem to be a big priority.

I imagine over millions of returns it probably evens out. Also, for the majority of taxpayers in the US, the tax table does things like:

AGI is 40,001 to 40,025 then your tax is X dollars.

Being accurate to the penny isn't worth the trouble.

Yes, practically I can see why. But when my W2 contains cents, and my tax forms make me sign for accuracy under penalty of whatever blah blah, seems pretty odd that they don't accept my cents and then do their own internal rounding. Maybe it was just the tax software I was using.

Sounds like the start of a movie script

Office Space

https://youtu.be/yZjCQ3T5yXo?si=xGGrxafG2zzA0IIR

I'm assuming you did the correct thing and engaged an an Office Space-esque penny-stealing operation after learning this? :)

I had such case too, the solution is simple:

round in favor of the bank / financial institution you are working for

No, it does not work this way. Any good accountant will see a different in values, even smallest one, as a sign of an incorrect calculation. Does not matter which way it goes, they will feel compelled to figure out who is wrong. At least a good accountant will.

There is no accounting error; let's say customer has purchased / used a service for 1.433 USD.

You issue an invoice for 1.44 USD (aka, amount due), then the 1.44 USD is used as a basis for accounting and is all consistent.

Then, if you are a nice company and the situation applies in your case, you may issue a credit in favor of the customer for 1.44 USD - 1.433 USD that will be used as a discount on a future invoice

The best part is that the moment where you decide to issue the credit invoice or not, is the perfect moment to track the rounding errors and even keep a very detailed journal of the entries (e.g. for auditors).

You added 10 of those items as inventory with a total value of 14.33, then you sold each individually as a total value of 14.40. After that transaction, your inventory account has -0.07 on it, but there aren't any items at all there.

From experience, those differences surface during stock taking. Amd most companies are really bad at that. And if they surfacey they are corrected by inventors adjustments (in unit of measure, not value, which is a differwnt can of worms). As long as those adjustments aren't to extreme, nobody really cares.

A good accountant so will sooner or later investigate those rounding errors, as they will show up somewhere ultimately. And a general policy of rounding in one direction is the last thing you want an auditor to find.

So accountants are like number detectives doing what's essentially debugging work just like a coder would?

They design the system, detect the failures, explain and correct them. So, their work even is more like programing than your comment implies.

One can use more than 2 decimal places for rates, but final invoicing has to be two decimal places (atleast in most countries). Banks/tax authorities dont carry anything beyond 2 decimal.

Eg: fuel is usually priced 3 decimal, so 4 gallons x 25.5444 usd/gallon gives = $102.1776 to 4 dp, but will be billed as $102.18

Any rounding discrepancies simply get posted to a rounding-error account. For example, oracle's ledger will complain if there is rounding and no rounding-error account to post to. https://support.oracle.com/knowledge/Oracle%20Cloud/2411363_...

That is absolutely not how it works. Rounding is exactly specified in the underlying contract always and you need to implement the correct rounding. For example, here is the rounding table for compounding calculations in the ISDA definitions (these are very standard for a wide range of contracts, but this particular table is for various overnight swap rates used in interest rate derivatives)[1].

[1] https://globalmarkets.cib.bnpparibas/app/uploads/sites/4/202...

Interesting side note:ASME also has a standard for rounding on engineering drawings. A few years back I had to build a custom function in Excel to match the standard, because our calcs weren't matching the customer's calcs.

And how do they round ties? Does 0.00005% round to 0.0001%? Is tie breaking usually included in such contracts?

For these benchmarks, yes, that is defined.

Where issues could come in is when these things are multiplied with a bunch of other numbers (each number with defined rounding but not after each operation) and then have some defined rounding at the end. There different computer numerics could in give slightly different results, but those can easily be resolved on settlement (for small stuff that stays well within the back offices - at least that is how I remember it).

Also, not totally unusual for one or both participants to forget about some rounding they might have agreed bilaterally if it was some one off etc.

I've worked in banking.

I assure you, I would have had a million bugs filed on that before it even hit production.

Heh. But usually it's the other way around unless they remembered to specify it the right way. Forgiving $0.01*N customers is cheaper than dealing with an irate customer.

People care less about the dollar value than about reconciling. If there is some external system they should match, they really want it to match exactly.

https://wiki.c2.com/?BankersRounding

Reply on news.ycombinator.com