Positive Pay Exception Codes Explained: PNI, PVE, and Every Exception Reason

Last updated July 2026.

A positive pay exception is the bank telling you that a check presented against your account does not match the issued check file you sent. The most common reason codes are PNI, paid no issue, meaning the check is not in your file at all, and PVE, payee validation exception, meaning the payee name on the check does not match the payee you reported. Others cover amount mismatches, duplicate serial numbers, checks paid against a void, stale dated items, and items the bank could not read a serial number from. Every exception needs a pay or return decision from you, usually before a cutoff the same business day, and if you miss the cutoff the bank applies whatever default you agreed to at setup.

What is a positive pay exception?

Positive pay works by comparison. You transmit a list of the checks you have written, and when a check is presented the bank checks it against that list on account number, serial number, and amount. If everything agrees, the check pays and you never hear about it. If anything disagrees, the bank does not pay and does not return it either. It parks the item as an exception and puts it in your treasury portal with a reason code and an image, and waits for you to say pay or return.

The important thing to understand is that an exception is not an accusation. Most exceptions at most companies turn out to be a process problem on your side rather than fraud on someone else's. That does not make them safe to rubber stamp, because the small number that are fraud are exactly the ones the service exists to catch.

Positive pay exception codes and what they mean

Reason codes are set by each bank, so the three letter abbreviations differ between institutions. The underlying reasons are consistent across published US bank guides.

What does PNI mean in positive pay?

PNI stands for paid no issue. The bank received a check drawn on your account and found nothing in your issue file with that serial number, so it has no way to confirm you wrote it. Some banks call the same thing paid not issued or an unmatched item.

Before treating a PNI as fraud, check your own upload history. The single most common explanation is that a legitimate check run went out the door and the issue file for it was never transmitted, or was transmitted and rejected for a formatting problem that nobody chased. If your bank rejected the file because Excel ate the leading zeros off the check numbers, every check in that run will come back as a PNI. The positive pay file format reference covers the formatting rules that cause those silent rejections.

If the upload did go through and the item still is not in it, look at the check image. Compare the check stock, the signature, the font of the printed amount, and whether the serial number falls inside a range you have actually used. A serial number well outside your current range is a strong fraud signal.

What does PVE mean in positive pay?

PVE stands for payee validation exception, and it only appears if you are enrolled in Payee Positive Pay, the version where the bank also reads the payee name off the check image and matches it against the payee in your file. Standard positive pay matches on account, serial, and amount only, so it will never raise a PVE.

Payee exceptions skew heavily toward false positives at first, because your accounting system and the printed check may render a name differently. A vendor stored as "Acme Supply Company, Inc." but printed as "Acme Supply Co Inc" can trip the match, and so can a payee name longer than the field width your bank spec allows, since the file carries a truncated version. Once the naming is cleaned up the volume drops sharply, and the exceptions that remain are the ones worth looking at, because an altered payee on an otherwise legitimate check is precisely what this service catches.

How long do I have to decide a positive pay exception?

Banks set a same day cutoff, and it is early. Many US banks put the deadline somewhere between late morning and early afternoon in the account's home time zone, and the bank publishes the exact time in your service agreement. Miss it and the bank applies the default decision you chose at enrollment.

That default matters more than most people realize. Default pay means unresolved exceptions get paid, which keeps vendors happy and leaves you exposed. Default return means they get returned, which is safer and will occasionally bounce a legitimate check to a real supplier. Whichever you pick, the practical answer is the same: assign a named person and a named backup to check the exception queue every business morning, because a control nobody looks at is not a control.

Should I pay or return a positive pay exception?

Work from evidence, not from convenience. The check image is the evidence, and your own records are the corroboration.

• Return when the serial number is outside any range you have issued, the check stock or signature looks wrong, or you can find no purchase order, invoice, or ledger entry that would justify a payment to that payee.
• Return when the amount is materially higher than the issued amount and you cannot explain the difference. An altered amount is one of the classic check fraud patterns.
• Pay when you can tie the item to a real invoice and a real approval, and the exception has an ordinary explanation such as a reissue at a corrected amount or a payee name formatted differently from the file.
• Pay and then fix the process when a whole batch appears as PNI on the same day. That is a missing upload, not eight separate frauds.

When you are unsure, returning is the recoverable choice. A returned legitimate check annoys a supplier and gets reissued in a day. A paid fraudulent check starts a claim process where your recovery rights depend on having used the fraud controls the bank offered you.

How do I research an exception quickly?

The clock is the problem. You have a couple of hours and the answer usually lives in a stack of statement PDFs.

Start with the serial number. Convert your recent bank statements into a spreadsheet so the check numbers sit in their own column, then filter on the serial in question. That tells you immediately whether a check on that number already cleared, which turns a suspected fraud into a duplicate serial in about thirty seconds. Our bank statement converter produces dated rows with the check number, amount, and running balance kept separate, which is what makes that filter possible at all. Sorting a converted year by check number also exposes the reuse patterns that cause recurring duplicates.

Next, match the amount against your payables records for that vendor. Then check whether the issue file for that check run was actually accepted, not just sent. Doing this monthly rather than only under deadline pressure is the better habit, and it falls out naturally when you reconcile the bank statement against your ledger each period. If you are staring at a check image and something feels off about the document itself, the signs covered in how to tell if a bank statement is fake apply to check stock too.

How do I get fewer positive pay exceptions?

Almost all recurring exception volume comes from four fixable causes.

Upload the issue file as part of the check run, not as a separate task someone remembers later, and confirm acceptance rather than assuming it. Report voids to the bank the same day you void in the ledger, so the void reaches the bank before the check reaches a teller. Never reuse check serial numbers, and when you reorder stock, start the new range above the highest number ever issued rather than back at 1001. Standardize vendor names to match what actually prints on the check, and keep them inside the field width your bank spec allows, which is what kills most payee exceptions.

The structural fix is writing fewer checks. Every check is a piece of negotiable paper carrying your account and routing numbers through the mail, and no matching service changes that. Teams that shift vendor payments onto ACH and card rails, often as part of moving to automated accounts payable, cut check fraud exposure and the exception queue at the same time. ACH has its own controls worth understanding, and the NACHA file format reference covers how those payment files are structured.

Positive pay is worth the setup effort either way. Check fraud remains one of the most persistent payment fraud types reported by US businesses, and the issue file is the cheapest control that actually stops a bad item before the money leaves.