I ran in to this problem a little while ago where I had an AWS account number that had leading zeros as part of it, and needed to use it in a CloudFormation template. All of my templates are YAML-based now (rather than JSON), and while it's generally a great experience sometime YAML will cause some surprises.
When using YAML it will "helpfully" recognise that a particular field is a number, and remove the allegedly unimportant leading zeros from it. Obviously this makes the number invalid, breaking all kinds of things down the line.
Wrapping the number in quotes didn't help, as it was still recognised as a number as part of the template parsing. I suspect that behind the scenes all YAML gets converted to JSON before being actually used, which meant that just addressing the problem in YAML didn't fix it. While I might have been able to use JSON as my source and forced it, I didn't want to convert my entire stack to JSON just for this.
While the 12-digit number-only format is supported in most all the places that account identifiers are specified, they are not the only way to specify accounts. The fix is use the alternate format for AWS accounts: use the full account ARN.
ACCOUNT-ID with your own number (assuming you're not in one of the freak partitions) and the leading zero will be preserved. The important bit here is the path of
root at the end which is how the whole account can be specified as an ARN.
Hopefully this saves someone else a bit of stuffing around!