How to test a positive pay file before go-live
Before you rely on positive pay to catch check fraud, you need to know your file actually loads at the bank. A file that fails on go-live day means your checks are not protected and your exception window may already be closing. The fix is to test first: generate a small, real batch, validate it, and submit it to the bank through a test path before any live check depends on it.
This walkthrough covers the practical steps. The exact field layout is account-specific, so the goal is not to guess a spec but to prove that the file you produce matches the spec your bank gave you.
Step 1: Get the file spec from your bank
Start with your bank's written issued check file specification. Positive pay files are usually delivered as delimited (CSV), fixed-width, or Excel, and the required fields are consistent across banks even when the layout differs. Most specs ask for the account number, check number, amount, issue date, and an issue/void code, with payee name required only if you use payee positive pay.
Do not start building until you have the spec in hand. If your bank has not published exact column positions, treat the layout as account-specific and build it from their document rather than copying another bank's format. You can map a layout you have been handed using the custom format builder, and the field-by-field reference is on the positive pay file format page.
Step 2: Generate a small real batch
Use real check data, not made-up numbers, but keep the batch small. Five to twenty checks from a recent run is enough to exercise the format without creating a large cleanup job if something is wrong. A small batch makes it easy to read every row by eye and to confirm the totals by hand.
Generate the file in the positive pay generator using the layout your bank specified. Watch the details that banks reject on: amounts should follow the spec exactly (a decimal point versus an implied decimal is a common mismatch), the issue date format must match, and voided checks need the correct void code rather than being left out.
Step 3: Run the built-in validator
Before the file leaves your computer, run it through the file validator. The most common rejection causes are formatting problems, not bad check data: missing delimiters, fields that are the wrong length, a header or trailer row the bank did not ask for, or a missing required field such as a check number or amount. Catching these locally is faster than waiting for the bank to bounce the file.
The validator also reports the item count and total amount it reads from your file. Write both numbers down. You will use them in the next two steps to prove the file ties out. For a full list of what trips up a load and how to clear each one, see the positive pay file rejected page.
Step 4: Submit a test or sample file to the bank
Ask your treasury contact how they want a test submitted. Many banks support a true test mode: they enroll the account with an inactive status, or you load against an inactive template, so the items are marked as test data. Test items do not display in the issue warehouse and are not used to match presented checks, which means you can prove the upload works without affecting real exception decisions.
If your bank does not offer a separate test facility, send the sample file to your treasury or implementation contact and ask them to confirm it loaded. Either way, the point is the same: a human or system at the bank confirms the file was accepted before you depend on it.
Step 5: Confirm the count and totals tie out
After the bank loads the file, compare what their system reports against the numbers you recorded from the validator. The bank's total items should equal your row count, and the total amount should equal your accumulated dollar amount to the penny. If either figure is off, something dropped or transformed during the load, and you need to find it before go-live, not after.
If you spot an incorrect detail before the file is approved, cancel it, fix the row in your source data, regenerate, and re-upload. Do not approve a file you know is wrong; once a file is approved to the bank's core, you usually cannot pull it back.
Step 6: Fix common rejection causes and re-test
If the test fails, the cause is almost always one of a short list:
- Format mismatch: wrong delimiter, extra columns, or fixed-width fields that do not line up with the spec.
- Amount formatting: a literal decimal where the bank expects implied cents, or the reverse.
- Date format: the file uses a date style the bank does not accept.
- Missing required field: a blank check number, amount, or account number.
- Transmission settings: wrong SFTP credentials or upload path, which look like a load failure but are really a delivery problem.
Fix the file, run the validator again, resubmit the test, and repeat until the bank accepts it cleanly and the totals tie out. Only then move to live submission, and confirm your daily cutoff time so your first real file lands before the bank's deadline.