The devil is in the details. Those "some adjustments" are not exactly trivial, if they need to be correct and undisputed. And different people may have different requirements for what is "correct".

Things get trickier when the company is multinational. You might even be prevented by law from handling the salary data of one country in another.

(FWIW, I have some years experience as a line manager in a multinational, with reports in another country; this was not always a breeze even though from what I know, we were a decade or two ahead of most multi-nationals in the level of international integration of corporate IT.)

But in production this takes 3 Java developers, 2 Oracle "specialists", one year and a couple million dollars to implement.

Ah, back when I was a programmer without any SQL/DBA skills, I thought like this too. Now I know better than letting unskilled workers (e.g. lots of so-called DBAs, most developers) develop schemas or queries.

If you pay them all the median wage, that won't hurt convergence.

That was my thought as well. They need those numbers (or some contractor that handles payroll need those numbers) for reporting taxes etc anyway. There's no way that it is "cumbersome" to implement. I mean they need to total them up (salaries) for the quarterly reports -- and making one of those must be far more "cumbersome" than to report on a couple of core business stats...

So what you're saying is all that non-technical HR people have ever to do is normalize all of the employee salary data and load it into a database and then run this query? Easy peasy!