Fixed-Width vs CSV Positive Pay Files: What's the Difference?

When your bank asks you to upload a positive pay file (also called a check issue file), it expects one of two broad shapes: a fixed-width text file or a delimited file, usually CSV. They carry the same information, the list of checks you issued so the bank can flag anything that doesn't match. They just arrange that information differently, and getting the arrangement wrong is the most common reason a first upload gets rejected.

This page explains how the two formats work, why a bank picks one over the other, and how to produce whichever one your bank wants without retyping anything.

The short version

A fixed-width positive pay file places each field at a specific character position on the line. The check number always starts at, say, column 11 and runs 10 characters wide, the amount always sits in a fixed block, and short values get padded with spaces or zeros to fill the column. Nothing separates the fields except their position.

A CSV (comma-separated) file puts a comma between each field instead. Values can be any length, and the comma marks where one field ends and the next begins. Tab-delimited files work the same way using a tab character instead of a comma.

Same data, two packaging styles. Here is the same check in both:

• CSV: 123456, 11/26/2024, John Doe, 2500.00, 987654321
• Fixed-width: 123456 11262024John Doe 0000025000987654321

Notice what changed in the fixed-width line. The date lost its slashes. The amount 2500.00 became 0000025000, zero-padded on the left and with the decimal point removed so it reads as cents. The payee name was padded out with trailing spaces to fill its column. Those mechanics are exactly what trips people up.

How fixed-width fields actually work

A fixed-width layout is defined by a position map. For each field the spec tells you three things: where it starts, how many characters it occupies, and how to fill the leftover space. The rules that matter most:

• Padding and justification. Text fields like the payee name are usually left-justified and padded with spaces on the right. Numeric fields like the amount are usually right-justified and padded with zeros on the left.
• Amounts in cents. Many fixed-width specs strip the decimal point and express the amount as an integer number of cents. $2,500.00 becomes 250000, then gets zero-filled to the field width (0000250000). Read the spec carefully here, a misplaced decimal is the single most expensive mistake in positive pay.
• Date format. Fixed-width files often drop separators, so a date becomes MMDDYYYY or YYYYMMDD with no slashes. The width is fixed at 8.
• Exact line length. Every record is the same total length. Some banks reject a file if a line is even one character too long or short, so trailing padding is not optional.
• Record type and void codes. Some layouts begin each line with a code that marks the row as an issued check, a void, or a header. If your bank uses one, it has to sit in the right position too.

Fixed-width is the older convention. It came out of mainframe accounting systems, and banks that built their import process around that era often still prefer it because the rigid structure makes errors easy to detect, every field is exactly where it should be or the file is wrong.

How CSV layouts differ

CSV is more forgiving because the commas do the work that positions do in a fixed-width file. You don't pad anything. 2500.00 can stay as 2500.00, the date can keep its slashes, and the payee can be any length. The spec for a CSV file is mostly about column order and a few formatting choices:

• Which column holds which field (check number first or account number first, for example).
• Whether the file has a header row of column names, and whether the bank wants it removed.
• Date format, since even in CSV the bank may insist on MM/DD/YYYY versus YYYY-MM-DD.
• Whether the amount includes a dollar sign, commas as thousands separators, or just a plain number.

Because CSV opens in Excel and is easy for people to read and edit, many banks, especially regional and community banks running modern treasury platforms, accept or even prefer it. The required fields are the same in both formats. Across published bank specs the common core is check number, issue date, amount, and account number, with payee name required by some banks and optional at others.

When does a bank use each?

There's no universal rule, and you cannot guess from the bank's size. What you can count on is this: the bank publishes its own specification, and that document is the only source that matters. It tells you the format, the field order or positions, the date format, the amount convention, and whether a header or trailer record is required. You'll usually find it inside the treasury or business banking portal under positive pay, fraud services, or cash management, or you can ask your treasury contact for the "check issue file format" or "positive pay file specification."

A few practical patterns hold up. Older or larger institutions running legacy systems lean toward fixed-width. Banks on newer treasury platforms frequently offer a CSV option and sometimes a configurable mapping screen. Many banks let you choose either format, in which case CSV is the easier one to produce and audit by eye. For exact field positions, always defer to your bank's PDF rather than any general description, including this one. We don't publish other banks' position maps because they change and getting one digit wrong defeats the purpose.

Producing the right file without retyping

Your accounting software already has the data, the check number, amount, payee, and issue date for every check you wrote. The job is reformatting that into your bank's exact layout. QuickBooks, for instance, cannot export a positive pay file natively, so something has to sit between your register and the bank's upload page.

PositivePayMaker is a free, browser-based tool that does exactly that reformatting. You export your check register from QuickBooks, Excel, or any system that produces CSV, drop it in, and it builds the file your bank expects. It ships with layouts for 11 banks, including six built from published specifications, plus a custom format builder where you set field positions, padding, date format, and the amount convention to match any fixed-width or delimited spec your bank hands you. It also includes a validator to check a file before you upload it. Everything runs inside your browser, so your check data never leaves your computer.

If you process a high volume or want desktop software that pulls directly from QuickBooks, 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 supports well over 100 bank formats. Treasury Software's Bank Positive Pay is an installed Windows product, roughly $29.95 to $89.95 a month depending on tier, with 350-plus layouts. Those make sense for shops that want native integration or a very long built-in bank list. For most small businesses, a free browser tool plus a custom format covers the same ground.

Always verify the first file

Whatever you use, treat the first file you generate as a draft. Open it in a plain text editor and confirm the field positions or columns line up with your bank's spec, the amount convention matches (cents vs. dollars, padded or not), and the date format is correct. Then upload a small test file, or send it to your treasury contact, before you rely on it for a full check run. Banks reject files for tiny formatting reasons, and catching that on a two-line test beats finding out when a vendor's check bounces.

Related reading: the positive pay file format reference breaks down each field in more detail, and the QuickBooks positive pay guide walks through exporting your register.

Create your positive pay file