In this particular example, probably the function should be eliminated completely. It's easier to read (value x tax / 100) than to hunt for the spec of calculateTaxOverTransfer() to see what it does. (I'm ignoring the weirdness of representing tax in % instead of a float; that's probably another opportunity for a refactor).

Even if there is reasonable business justification to have a specific function to calculate taxes over transfer (maybe multiple callers, the logic is more complex than shown, or there's expectation that the rule might change) something named calc_tax() doesn't reduce the least of your ability to understand what it does.

If there's business ambiguity (like many types of taxes), then yes, you may need to differentiate which tax you're calculating. Even then, I still prefer the C convention and having a single function that receives a parameter indicating the tax to calculate, like calc_tax( tax_type, amount, rate ).

But one could argue that it's a different use case altogether, and you're better off by refactoring your code, and encapsulating the logic in a class that understands different objects passed as parameters for a calc_tax method.