TL;DR: Trying to bulk update one field in Account but being told Id is of incorrect type. Have checked and am positive it is of the correct type.

I am trying to perform an Account bulk update with dataloader. Each file is 500,000 records.

This update is to modify a single new field. The CSV is structed as such:



The update keeps failing with the following error message:

Account ID: id value of incorrect type: 001XXXXXXXXXXXXXXX

This seems straight forward enough but I can say with 100% confidence that the ID is correct. For each failure, I did a SOQL query to check the existence of the Id and all have returned. The Ids were exported with Dataloader before I began trying to update this field. The only thing I can think of is that a lot of these will be Person Account records but there is no SF docs saying this is a problem and Dataloader does not offer an option to update by Person Account.

The field being updated is a simple string field; no look ups or formulas involved. It is the same string in all cases and only six characters long. And the primary SF Id is being used, no external Ids.

Has anyone else encountered this problem?


You could get this message when the casing of the letters in the Id is off. The 18 character id consists of the actual 15 character id, with some sort of capitaliziation checksum appended to it.

So the last three characters will let you determine what the capitalization of the other charachters should be.

For instance, this Id is correct; 0015800001ZD7pDAAT. If I run a script like this;

Database.update(new Account(Id = '0015800001ZD7pDAAT'));

it will succeed. However, if I change one of the characters to the other case, it will give me the exact error you are getting:

Database.update(new Account(Id = '0015800001ZD7pdAAT'));

Will yield System.DmlException: Update failed. First exception on row 0 with id 0015800001ZD7pdAAT; first error: MALFORMED_ID, Account ID: id value of incorrect type: 0015800001ZD7pdAAT: [Id]

This is because the checksum (AAT) tells the system which letter should be uppercase. In the second example, this does not match with the actual value, so the error occurs.

Note that querying on a malfored Id will not throw an error, it will simply not find a record for that Id.

  • This was my first thought as well as sometimes the Id is missing the last three 'checksum' figures. However, I don't think that's the issue in this case. If we take one of the Ids as it was extracted (0010Y00001FWI5XXXX last 4 characters changed ) it has the checksum intact. And comparing it via SOQL query to what is saved, the case of all characters match. – Don Feb 17 at 14:37
  • Hi Don, you use a script like used with your Id (copied from the CSV), does it work? Are there any triggers on account that may call updates? Are the ids that are getting this error all person accounts, and the ones that succeed all non-person account? – rael_kid Feb 18 at 17:29

I found the answer and it's as daft as you would expect. When I did the extract to get the Ids, it seems like there was an additional whitespace at the end of the Id. Using TRIM o the csv file fixed it and I'm now able to update. I don't know how the whitespace got there; I edited the second column to add in the value I wanted to update but never touched the Id column and to the best of my knowledge the extract doesn't append whitespace to the end of a record. So a stupid, silly mistake but one maybe that will help others in the future.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.