Positive Pay File Format: The Complete Guide

A positive pay file (also called a check issue file) is a list of the checks you wrote, sent to your bank so it can match presented checks against what you actually issued. If a check comes in that is not on the list, or the amount does not match, the bank flags it for your review instead of paying it. This is the single most effective control most small businesses have against check fraud. For the background on what positive pay does and why banks require it, see what is positive pay.

This page is the reference hub for the file itself: what fields go in it, how banks lay those fields out, and the small encoding details that cause most rejected uploads. Every bank wants the same handful of facts about each check. The disagreement is entirely about packaging.

The universal fields

Almost every positive pay format is built from the same core fields. The names differ; the meaning does not.

• Account number. The checking account the check was drawn on. Some banks want the full DDA number, some want it zero-padded to a fixed length, some include the routing number.
• Check number. The serial number printed on the check. This is the primary key the bank matches on, so leading zeros and length matter.
• Amount. The dollar value of the check. The format of this field causes more errors than any other (see implied decimals below).
• Issue date. The date you wrote or dated the check. Common formats are MM/DD/YYYY, YYYYMMDD, and MMDDYY.
• Payee. The name the check is made out to. Some banks require it (payee positive pay), many treat it as optional, and most cap its length.
• Issue or void code. A flag marking whether this row is a normal issued check or a void/stop. More on this below.

A few banks add a transaction type or status field, an account name, or a constant filler field. But if you can produce those six values cleanly, you can produce almost any bank's file.

Fixed-width vs delimited

There are two ways to arrange those fields in a text file, and your bank's spec will use one of them.

Delimited (CSV). Fields are separated by a comma (sometimes a tab or pipe). Column order is fixed, but field width is not, so 1024 and 0001024 can both be valid check numbers. CSV is the more forgiving format and the more common one for online banking uploads. A row looks like 123456789,1024,1500.00,06/14/2026,Acme Supply,I.

Fixed-width (positional). Every field occupies an exact column range, padded with spaces or zeros to fill its slot. There are no separators; the bank reads characters 1 to 10 as the account, 11 to 20 as the check number, and so on. A single character out of place shifts every field after it, which is why fixed-width files fail silently and look fine to the human eye. This format comes from mainframe banking systems and is still standard at many large banks. Chase and Huntington both publish positional layouts; see the Chase format page and the Huntington format page for the exact column maps.

Implied-decimal amounts

The amount field has two encodings, and picking the wrong one turns every check into a check off by a factor of one hundred.

Explicit decimal: the amount is written as you would read it, 1500.00. Implied decimal: the decimal point is removed and the last two digits are assumed to be cents, so 1500.00 becomes 150000 and 1.23 becomes 123. Fixed-width specs almost always use implied decimals, often zero-padded to a set width like 000000150000. If your bank uses implied decimals and you send explicit ones, a $1,500.00 check is read as $1,500,000.00 and the file is rejected or, worse, accepted wrong. Always confirm which convention your bank's layout uses.

Void codes differ by bank

The issue/void flag is where banks disagree the most. Common conventions include:

• A single letter such as I for issued and V for void.
• A different letter for cancel or stop, such as C or CN.
• A numeric status code, where 1 means issued and 2 means void, or similar.
• Two separate columns, where one marks the record type and another carries a void override amount.

Some banks do not accept voids in the issue file at all and want them handled separately in online banking. There is no universal void code, so this is the field to verify line by line against your bank's written spec.

Header and trailer records

Many fixed-width formats wrap the check rows in a header record and a trailer record. The header usually carries a record-type marker, the account or company ID, and the file date. The trailer usually carries a record count and a control total (the sum of all check amounts), which the bank uses to confirm nothing was truncated in transit. If your bank's spec calls for a trailer total and your file is missing it or the total does not reconcile, the upload will fail. CSV uploads through online banking often skip header and trailer records entirely; positional batch files almost always require them.

Build the file without guessing

QuickBooks cannot export a positive pay file natively, and neither can most small-business accounting tools. The paid desktop products that fill this gap are Windows-only and not cheap: as of 2026, Big Red Consulting's PositivePay File Creator runs about $119 the first year and $99/year after (source), and Treasury Software's Bank Positive Pay runs roughly $360 to $1,080 per year (source).

PositivePayMaker is a free, browser-based alternative. It runs entirely on your computer, so your check register never leaves your browser, and it includes published layouts for banks like Chase and Huntington plus a custom format builder for any spec your bank hands you. If you keep your books in QuickBooks, the QuickBooks positive pay guide walks through exporting your check register and mapping it. Whatever tool you use, run the first generated file through a file validator and confirm it with your bank before relying on it. Banks change their specs, and the only file that counts as correct is the one your bank accepts.

Create your positive pay file