This sanity test and message is generated within the extension during the recurring payment job, as a precaution before talking to the iATS server. It doesn't depend on the customer record saved on the iATS server, and changing that won't have any effect.
For details see line 240 of this file:
An interesting workaround is you can make a profile that includes the membership end date for bulk updating memberships, then edit the membership end date there, and save. It won't throw an error. Not sure what the unintended consequences may be.
I've raised this as issue #1126 in GitLab. From the discussion, it appears that this was implemented as a 'feature' in the past but it is unclear why this was necessary. Hopefully this issue will be resolved at some point in the future but this may take some time as we need to ensure that it won't cause a regression for existing users.
As a workaround in ...
Table civicrm_iats_customer_codes does not have the correct Customer id to match what iATS has on file. This is likely because you edited or merged the customer at some point and something got messed up in the process.
You can use the iATS web portal to view what customer code (I know you said you found it already--but the next person might not know where to ...
On a CiviCRM Contribution page - the select Future start date of a Recurring Contribution is added by our iATS Payments Extension (Configuration for it lives on the iATS Settings page).
Because it’s payment processor specific (it requires ability to tokenize a card) I’ve not created a field for it in Webform CiviCRM module.
Having said that - here’s what ...
The short answer is:
Unfortunately Webform CiviCRM integration does not currently support selecting the start date for a recurring contribution.
The longer answer is that it would not be impossible nor incredibly complex to add this field as a supported option for the CiviCRM integration to allow you to expose this option via Webform & CiviCRM.