Record normalization
Parseable records are restored to 94 characters with consistent line boundaries and valid hierarchy.
Repair padding, line endings, hashes, counts and control totals.
Continue with a tool that fits the next step in this workflow.
Repair is appropriate when values can be derived from the existing records without deciding who should be paid or how much. Examples include stale counts, hashes, totals, controls, line endings, and padding.
Parseable records are restored to 94 characters with consistent line boundaries and valid hierarchy.
Batch and file counts, hashes, debit totals, credit totals, trace sequences, block count, and padding are regenerated.
Keep the original, the repaired output, validation results, and a comparison of changed records. A structurally repaired file still needs payment approval and bank-specific review.
Only when the record remains interpretable without guessing payment data. Truncated or shifted fields may require a new export from the source system.
It should not invent business instructions. Those changes belong in an authorized editing or source-system workflow.
A second validation confirms the rebuilt hierarchy and controls and exposes any non-repairable findings that remain.
Technical explanations are checked against these primary sources. Bank-specific requirements can be narrower than general format guidance.
Sources reviewed August 20, 2026. Nacha owns and maintains the linked materials.