Another trick to manage cleverness (or even just messiness) is to hide the code in a well-named function, so readers can understand what it's doing in the context of the rest of the code and only have to delve in when they need to.
Move the code that should be clever to a separate function, then add the clever in a single commit.
People tend to tolerate clever code that is out in leaf functions they don’t have to step through, and knowing they could revert the change makes them tolerate the clever longer.
My favorite recently is a class named CustomerCommandMapEmbelisherConverter.
It's not a good name. Nor is it concise, informative or anything vaguely useful.
But I get the strong feeling it comes from someone spouting off a line along the lines of "we need to name things for what they do" and then someone else just coming up with that.
In your case I'm going to guess doBillCustomer() is about 2.5k lines long with a copy of its entire logic duplicated and it branches based on annual or monthly billing and subtle bugs have been fixed in one implementation but not the other and now they are diverged such that they are only 93% the same but that means all bets are off. There are 15 levels of nesting and it interacts with at least 5 external systems during all of that.
