I used to do the ACH files for a large cellular provider. The thing that surprised me the most, and which you won't find by reading the spec, is that very clearly some banks present a fixed-width text field to their employees and the employee can then key in whatever the heck they want with no further validations about whether it conforms to spec when they are done. We would routinely get back returns where the reference #s to correlate back to the original transaction had obvious typos and now referenced transactions we had never sent, or where the date field was off by 1 and partially in the account field (somebody hit delete), or where the name field ran over or started early. It would always be some small bank you had never heard of, and the only conclusion I could come up with was that I needed a better manual reconciliation interface than I had expected I would to handle letters in numeric fields and fixed-width fields not starting and ending in the right place.

The second most surprising thing was that we'd get back returns after a full year had elapsed. Most return reasons have time limits, but banks will push through the fraud reason without apparent limit and you'd better be ready to handle it.

The third most surprising thing was the account verification system - you 'verify' by sending through a special transaction and waiting a week. If it hasn't returned to you after a week, must be good! I don't think anybody designing a system today would come up with such a mechanism, but that's what we have for ACH...