The field layouts banks ask for, side by side, plus the Excel formatting traps that get an upload rejected. Convert your bank statement here and paid check numbers, dates, and amounts come back in columns, which is how you prove the checks the bank paid match the file you sent. Start free, no credit card.
Upload your bank statement
Drop file here or click to upload
PDF, JPG, PNG, BMP, HEIC, TIFF, MT940
Uploading...
A positive pay file is the issued check list you send your bank so it can match every check presented for payment against what you actually wrote. Nearly every US bank asks for the same four fields: check serial number, issue date, check amount, and account number, plus the payee name if you are enrolled in Payee Positive Pay. The layout is where banks differ. Some want a comma delimited CSV with the header row and totals stripped out, others want a fixed width text file with zero padded amounts and an implied decimal point, and each bank publishes its own field order, date format, and issue or void indicator. Ask your treasury contact for the spec sheet before you build anything. Last updated July 2026.
The concept is simple. The file is fussy, and the bank rejects the whole batch rather than the one bad row.
There is no national standard for the issue file the way NACHA standardizes ACH. Field order, delimiters, date format, and record length are set by each bank, so a file that loads perfectly at one bank fails at the next and a bank change means rebuilding the export.
Check number 000451 and issue date 070126 are text that looks like a number, so Excel drops the leading zero and the field arrives one character short. Banks that validate field length reject the row, and banks that do not may match it to the wrong check.
A report exported straight out of an accounting system carries a title row, column headings, and a grand total line. Most bank uploads expect data rows only, so those three lines alone are a common cause of a failed file.
Fixed width layouts frequently use an implied decimal, so $238.00 is written as 000000000000023800 with no period at all. Send 238.00 into a field that expects implied cents and the bank reads it as a very different number.
QuickBooks Desktop and QuickBooks Online do not produce a bank ready positive pay file out of the box. The usual workaround is a custom check report exported to CSV and reshaped by hand every check run, or a paid third party add on.
When an item does not match, the bank posts an exception and you have a cutoff, often late morning, to decide pay or return. Miss it and the default decision applies, which is why the research has to be fast.
The statement side of the job. Not the issue file itself, but the paid check data you need to check it against.
Every check the bank actually paid comes back with its date, check number, description, amount, and the running balance, so the paid side of positive pay stops being a PDF you read line by line.
Serial numbers arrive in their own column rather than buried in a description string, which is what makes a lookup against your issued check list actually work.
When the bank flags a check that is not in your file, you need to know whether it cleared before, whether the serial was reused, and what else posted that day. That is a filter on a spreadsheet, not a read through a document.
Two checks paid on the same serial number is a standard exception reason. Sorting a converted year of statements by check number surfaces the reuse in seconds.
An .xlsx workbook for the working paper, or a CSV you can reshape into whatever column order your bank spec asks for.
Nothing connects to your bank or to your treasury portal. You upload a statement you already have and download a spreadsheet.
The order that keeps you from building the file twice.
Ask treasury services for the positive pay file specification for your account. It tells you delimited or fixed width, the field order, the date format, whether amounts carry a decimal point, and whether the file needs an issue or void indicator.
Tip: Ask whether they will map a custom layout. Many banks will.
Pull a check report from your accounting system for the check run, keep check number, issue date, amount, account number, and payee, then strip the header row and totals and format the number columns as text so leading zeros survive.
Tip: Format the check number column as Custom with the right count of zeros.
After the checks clear, convert the bank statement here and match paid serial numbers and amounts against the issue file you uploaded. Anything paid that you never issued, or issued at a different amount, is what the bank should have flagged.
Tip: Run this monthly, not only when an exception appears.
Finance teams at US businesses that still write checks, which is most of them.
Own the fraud control program, sign off on the bank spec, and answer for any exception that gets paid by default because nobody decided in time.
Upload an issue file after every check run and get the rejection notice when the export shape drifts after a system update.
Handle positive pay for clients whose accounting system will not produce the file, which means building it in Excel each time.
Test whether the issued check list actually agrees to the checks that cleared, which requires paid check data in a form you can join on.
A positive pay file, sometimes called an issued check file or a check issue file, is a list of the checks your business has written that you transmit to your bank. When a check is presented for payment, the bank compares it against that list. If the account number, serial number, and amount all agree, it pays. If anything disagrees, or the check is not on the list at all, the bank holds it as an exception and asks you to decide whether to pay or return it, usually by a cutoff the same business day.
Payee Positive Pay adds one more comparison. On top of account, serial number, and amount, the bank reads the payee name off the check image and matches it to the payee in your file. That is the version that catches an altered payee name on an otherwise legitimate check, and it is the reason the payee field moves from optional to required when you enroll.
Banks word the requirement differently, but the core set is consistent across published US bank specifications. The four that are effectively always required are the check serial number, the issue date, the check amount, and the account the check is drawn on.
| Field | Required | Typical rules |
|---|---|---|
| Check serial number | Always | Digits only. Fixed width layouts zero pad it to a set length, often 10 to 18 characters. |
| Issue date | Always | Format varies by bank. MM/DD/YYYY in delimited files, and six or eight character forms such as MMDDYY or YYYYMMDD in fixed width files. |
| Check amount | Always | Either a plain decimal such as 2500.00, or zero padded cents with an implied decimal such as 000000250000. Never both. No dollar signs or thousands separators. |
| Account number | Almost always | The DDA the checks are drawn on. Some banks carry it in the file, others tie it to the upload profile instead. |
| Payee name | Only with Payee Positive Pay | Right padded to a fixed length in fixed width files, commonly 50 to 66 characters. Truncation rules matter because the bank matches what you send. |
| Issue or void indicator | Bank specific | A single character, often I for issue and V for void, so voided checks can be removed from the outstanding list. |
There are two archetypes plus a rarer third. The bank decides, and the answer is on the spec sheet.
| Format | What a row looks like | Watch out for |
|---|---|---|
| Delimited (CSV) | 000451,11/26/2026,2500.00,John Doe,987654321 | Strip header rows and totals. Field order is bank specific, not universal. Commas inside a payee name have to be quoted or removed. |
| Fixed width text | I00000000000000045100000000000250000 20261126John Doe | Every field has an exact character count. Numbers pad left with zeros, text pads right with spaces, and amounts usually carry an implied decimal. |
| XML | Tagged records inside a document wrapper | Uncommon for small and mid sized businesses. Usually appears in an ERP to bank integration rather than a manual upload. |
The implied decimal convention trips people up most often, because it is invisible until the bank reads the file. It works the same way it does in ACH, where NACHA file amounts carry no decimal point and the last two digits are always cents.
Neither QuickBooks Online nor QuickBooks Desktop generates a bank ready positive pay file natively. Intuit community threads on this go back years and the answer has not changed. You have three practical routes.
The manual route is a custom report. In QuickBooks Desktop, build a check detail or transaction report filtered to the bank account and the check run date, showing check number, date, amount, and payee, then export it to CSV and reshape the columns into the order your bank asks for. The reshaping is where leading zeros die, so format the check number and date columns as text before you save. The second route is a third party exporter that stores your bank layout and writes the file for you each run, which is worth the license fee once you are doing weekly check runs. The third route, if your bank supports it, is to ask them to map your existing export rather than force you to match theirs. Many banks will map a custom layout, which turns a recurring reformatting chore into a one time setup.
NetSuite, Sage, and Oracle Fusion all ship positive pay file templates that you configure per bank, so the work there is configuration rather than spreadsheet surgery. If you are moving statement data around those systems, the NetSuite bank statement converter and the Oracle Fusion bank statement converter cover the import side of the same close.
When a presented check does not match your file, the bank raises an exception with a reason code. The codes themselves are bank specific, but the underlying reasons are consistent across published US bank guides.
| Exception reason | What actually happened |
|---|---|
| Paid no issue (PNI) | A check was presented that is not in your issue file at all. Either fraud, or a check run whose file was never uploaded. |
| Amount mismatch | The serial number matches but the paid amount differs from the issued amount. |
| Payee validation exception (PVE) | The payee name read off the check does not match the payee in your file. Only applies on Payee Positive Pay. |
| Duplicate serial number | Two or more checks presented on the same serial number, usually a reused check number rather than fraud. |
| Paid against a void | The check matched an item you had already reported as voided. |
| Stale dated item | The check was issued before the stale date cutoff, commonly 180 days. |
| Missing serial number | The bank could not read a serial number off the item, so there is nothing to match on. |
Each of these has a different right answer, and the deadline to give it is the same day. The guide to positive pay exception codes works through what to do with each one.
Open the finished file in a plain text editor rather than in Excel, because Excel will show you a reformatted version of what is on disk rather than the bytes the bank will read. Count the characters in one fixed width row against the spec. Confirm the first line is a data row and not a heading. Confirm the last line is a data row and not a total. Check that the smallest check number in the file still has its leading zeros, and that one known amount is written the way the spec says, decimal or implied.
After the checks clear, close the loop from the other direction. Convert the statement, sort the paid checks by serial number, and match them against the file you uploaded. Anything paid that you cannot find in an issue file is worth understanding even if the bank never raised an exception on it, and reconciling the bank statement against your ledger is where that usually surfaces. If your check numbers are landing inside a description column rather than their own field, the running balance extraction page explains how the converter keeps the columns separate.
Positive pay is the version described above: you send the issue file first, and the bank matches against it. Reverse positive pay flips the burden. You send nothing in advance, and instead the bank sends you a daily list of checks presented against your account, and you review it and flag anything you did not write. It costs less and takes no file building, and it is weaker, because it depends on somebody at your end reviewing a list carefully every single business day. Banks generally position it for smaller accounts with low check volume. If you write more than a handful of checks a month, the issue file version is the one worth the setup.
It is the list of checks your business has issued, transmitted to your bank so the bank can match every check presented for payment against it. Matching items pay normally. Items that do not match become exceptions you must decide to pay or return, usually by a cutoff the same business day.
Whatever your bank specifies. In practice it is either a comma delimited CSV with no header row or a fixed width text file with zero padded fields. There is no national standard the way NACHA standardizes ACH, so the field order, date format, and amount convention come from your bank spec sheet.
Check serial number, issue date, check amount, and the account number are effectively always required. Payee name becomes required if you are enrolled in Payee Positive Pay. Some banks also want a single character issue or void indicator so voided checks drop off the outstanding list.
QuickBooks does not build one natively, in either the Online or Desktop version. Most people export a custom check report to CSV and reshape the columns to match the bank layout, use a third party exporter that stores the bank format, or ask the bank to map the QuickBooks export instead.
Excel treats 000451 as the number 451 and drops the padding. Select the column, choose Format Cells, then Custom, and enter the correct number of zeros, or format the column as Text before you paste the data in. Then verify in a text editor, because the saved file is what the bank reads.
PNI stands for paid no issue. It means a check was presented against your account that does not appear in your issue file at all. The two common explanations are check fraud and an internal one, that a legitimate check run was never uploaded, so check your own upload history before you assume the worst.
With positive pay you send the bank an issue file in advance and the bank matches against it. With reverse positive pay you send nothing, and the bank sends you a daily list of presented checks to review and flag. Reverse costs less and protects less, because it relies on somebody reviewing that list every business day.
No, and it is worth being clear about that. The issue file comes from your accounting system, because only that system knows what you wrote. What the converter does is the other side of the job: it turns your bank statement into spreadsheet rows with check numbers, dates, and amounts so you can verify that the checks the bank paid match the file you sent, and research exceptions across past statements.
The ACH equivalent, and it does have a national standard.
Read an ACH file as a sheet.
Statement data into QuickBooks.
Keep check numbers and balances in their own columns.
Get started converting bank statements to spreadsheets.
USD
per month
billed as
$288 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 2,500 pages |
| Pro AI Best accuracy | 500 pages |
Scale statement conversion across your team with automation.
USD
per month
billed as
$888 yearly
Choose speed vs accuracy when extracting
| Base AI Faster | 10,000 pages |
| Pro AI Best accuracy | 2,000 pages |
Enterprise-grade bank statement conversion and controls.
USD
per month
billed as
$ yearly
Choose speed vs accuracy when extracting
| Base AI Faster | pages |
| Pro AI Best accuracy | pages |
