What design pattern for functions that produce the same result but take different parameters?

I inherited a little over 1000 lines of spaghetti code. I can decompose it into a dozen methods that each create a FinancialTransactionObject but take different dates, amounts and other parameters to create their transaction.

My gut tells me to make each method its own class. So I can have a dozen classes inherit from a base class or interface with 1 method:

abstract FinancialTransactionObject Calculate();

and move the parameters either to constructors or make them public properties. Constructors mean I cannot reuse my instance and have to create a new object each time. Properties mean the consuming code can forget to set them. Leaving parameters on each method just gives me a dozen methods in separate files and doesn't feel object oriented.

It seems like a variation of this problem comes up often. Is there a good, consistent, industry wide design pattern to handle it?