Why your positive pay file got rejected, and how to fix it
A rejected positive pay file is almost never a problem with your checks. It is a problem with the shape of the text file you uploaded. Banks load these files with a strict parser that expects every line to follow one exact layout: certain fields, in a certain order, with certain widths or delimiters. When one line breaks the pattern, the upload stops, and you usually get a vague message like "file format invalid" or "record length error" with little detail about which row or which field caused it.
This page walks through the specific reasons a positive pay file gets rejected, in rough order of how often they happen, and how to correct each one. If you would rather not hand-edit a flat file, you can rebuild it cleanly from your check register with the PositivePayMaker tool and run it through the built-in validator before you upload.
Field length and record length errors
Fixed-width files are the most common positive pay format and the most fragile. Every field occupies a set number of characters, and every line must be the same total length. If your check amount needs 11 characters but the field is only 10 wide, the parser reads the overflow digit as the start of the next field, and everything after it lands in the wrong column. The bank reports a record length mismatch or rejects the whole file.
Causes worth checking:
- An amount or check number longer than the field allows (a $100,000.00 check in a field sized for five figures).
- A payee name longer than its field, not truncated to fit.
- Missing left-padding. Fixed-width amounts and check numbers usually need spaces or zeros in front so the field stays its full width.
- A stray tab, comma, or line break inside a field that pushes the line off its expected length.
The fix is to confirm the exact width of each field against your bank's specification and pad or truncate to match. A tool that lays the file out by column removes this class of error entirely, because it sizes every field for you.
Wrong date format
Dates cause more rejections than almost anything else because there is no universal format. One bank wants MMDDYYYY with no separators, another wants MM/DD/YYYY, and a third wants YYYY-MM-DD. If your file sends 6/9/2026 when the bank expects 06092026, the parser cannot read it. A single-digit month or day with no leading zero is a frequent culprit, because exported registers often drop the zero.
Check three things: the order of month, day, and year; whether separators are required or forbidden; and whether months and days are always two digits. Every issue date in the file must use the identical pattern. Mixing formats inside one file, even on a single row, will fail the load.
Bad amount formatting
Amount fields trip up registers that export currency for humans rather than for a parser. Common problems:
- Decimal points and symbols. Many fixed-width layouts use an implied decimal, so
1,250.00has to become125000(whole cents, no comma, no dollar sign). If the bank expects whole cents and you send a decimal point, the amount is misread. - The opposite case. Some CSV layouts do want the decimal. Sending
125000when the bank expects1250.00turns a $1,250 check into a $125,000 check on the bank's side. - Thousands separators. A comma inside an amount in a comma-delimited file splits one field into two and shifts every column after it.
- Negative or zero amounts. Voids and zero-dollar rows sometimes need a separate void record type rather than a $0.00 issue line.
Read your spec carefully for one detail: implied decimal versus explicit decimal. Getting it backwards is the error most likely to slip through, because the file loads successfully but the dollar values are wrong by a factor of 100.
Duplicate check numbers
Banks reject duplicates because a positive pay system cannot have two different definitions of the same check on the same account. Duplicates usually come from one of three places: uploading the same batch twice, a register that re-exports already-issued checks, or two real checks that were accidentally assigned the same number. Sort your file by check number and scan for repeats before uploading. If the duplicate is a genuine re-issue, your bank typically needs the original voided first, not a second issue record.
Account number problems
The account number ties every check to the right account, and banks validate it strictly. Rejections here come from a transposed digit, a missing leading zero, extra spaces, or formatting the account number with dashes when the bank wants digits only. Some banks also expect the account number on every detail line; others put it once in a header record. If your file has the wrong structure for where the account number belongs, the whole file fails. Confirm the exact account number, with any leading zeros, exactly as your bank lists it on the positive pay setup screen, not as it appears on a printed check.
Missing required fields
At minimum a positive pay record needs the check number, the issue date, the amount, and usually the account number; many banks also require the payee name. A blank check number, a zero where an amount should be, or an empty date will stop the load. This often traces back to the source export: audit the register your accounting system produced and make sure every row has every required value filled in before you convert it.
Use the validator before you upload
The fastest way to stop guessing is to check the file before it reaches the bank. The file format reference explains what each field should contain, and the validator in PositivePayMaker scans a generated file for the problems above: short or long records, malformed dates, amounts in the wrong shape, duplicate check numbers, and missing fields. It runs entirely in your browser, so your check data never leaves your computer.
If your bank is one of the published layouts (Chase and Huntington among them), pick it from the list. If it is not, the custom format builder lets you match any specification field by field, including fixed-width column positions, date format, and implied-decimal amounts. QuickBooks cannot export a positive pay file on its own, so a converter or a tool like this sits between your register and the bank either way.
When a paid desktop tool makes sense
For most small businesses a free browser tool covers the job. If you process high volumes, run many accounts, or want a desktop app with phone support, paid options exist. Big Red Consulting's PositivePay File Creator runs about $119 the first year and $99 a year after, is Windows-only, and its QuickBooks Online edition needs Excel installed. Treasury Software's Bank Positive Pay is an installed Windows product, roughly $29.95 to $89.95 a month, with a library of 350-plus verified layouts. Those tools may suit a busier accounts payable desk; for a one-account business the cost is hard to justify.
One last step every time
Whatever you use to build the file, verify the very first one with your bank. Layouts drift, and a bank may update its spec without much notice. Generate the file, validate it, upload a small test batch, and confirm with your treasury or business banking contact that the checks loaded correctly before you rely on it for a full run. After the first clean upload, the same configuration will keep working.