Workaround for contribution.payment_instrument_id
Summary: when a contribution is created as Pay Later, the payment method on the first payment should replace the contribution's payment method. In the long term, a better solution to handling the many payment methods per contribution problem is needed.
Background
A contribution's payment method (civicrm_contribution.payment_instrument_id) is a crufty historical artifact from the era before partial payments, and it's not currently editable when a contribution is edited.
By contrast, the payment method on payments (civicrm_financial_trxn.payment_instrument_id) is editable in the browser when editing a payment.
From an accounting perspective, it isn't clear what it would mean if the contribution's payment method was changed after one or more payments are received - should it replace the payment method on all of the payments?? Reports and search have not been refactored to use civicrm_financial_trxn.payment_instrument_id, unfortunately, so there is a motivation to make the contribution's payment method better reflect the reality of what happens.
One important, common scenario that causes a lot of grief could be better handled with a small change. When a Pay Later contribution is created, a payment method needs to be specified, but it may not turn out to be accurate. When a Pay Later contribution status is transitioned to Completed or Partially Paid due to a Record Payment action, the payment method for the payment could be used to update the contribution's. No other change in what goes in to the database is anticipated, and more particularly, no change in the financial accounting.
FWIW, this is a similar problem of many-to-one as the financial types of line items compared to the contribution's single financial type. It also developed because the introduction of the many-to-one conceptual model was not matched with the courage and resources to refactor the original one-to-one model.
A proper solution would be to get rid of the field on contribution records. Changes would be needed in view contribution, search, and reporting so that the actual payment methods used for the payments on a contribution were used consistently.
With the new Search Builder about to be released we might be on verge of a new era of accuracy and flexibilty. In a few short months, its results will be the basis of the data for a new era of reports. Let's aim to get accurate data on payment methods out in those two areas and then come back to address this long-standing problem.