While TCP (the protocol on which http/https is built) has error-detection in the form of a checksum on board (which triggers retransmissions), it's not bulletproof.
It is very rare, but numerous bit flips in the same packet could still result in a valid checksum. If the rest of the packet is still undamaged, those errors could travel all the way into your application. I'm conveniently skipping over error detection/correction in lower layers of the transfer here.
Generally, encryption algorithms include much stronger checksums, as part of the data security. TLS/SSL (over TCP) certainly does, so you conclusion is technically valid.
However, do note that this is very, very rare; on the same scale as errors in (non-ECC) ram, sata cables and disk storage (both on server and client side!).
For reliability purposes, to switch to https without targetting those other potential problems is silly and will never achieve "100%" reliability.
In my experience, it's just as likely the cause is with some other part of the system (application processing the uploaded data, maybe silent format conversion in the database, ...).
This whole problem applies to non-http protocols too.