Positive pay file formats and issue file layouts

A positive pay issue file (also called a check issue file, issued items file or positive pay upload) is the list of checks a business customer has written, sent to its bank so presented checks can be matched against it. Unlike ACH, which has the NACHA file format, or image exchange, which has X9.37, there is no industry-wide standard for issue files. Each bank defines a layout, and the customer's accounting or ERP system is configured to produce it.

The layouts vary, but the content is remarkably consistent.

The fields in an issue file

Example: fixed-width layout

Fixed-width files are the traditional format, especially from older accounting systems and mainframes. Each field sits at a set position. Here is an illustrative layout:

00123456780000010241000012500020261015IACME INDUSTRIAL SUPPLY
00123456780000010242000004877520261015IRIVERSIDE UTILITIES
00123456780000010198000002000020261009V
T000000000300000193775

Reading the first line: account 0012345678, check 10241, amount $1,250.00, issued October 15, 2026, payable to ACME Industrial Supply. The third line voids check 10198. The trailer says three records totaling $1,937.75.

Example: delimited (CSV) layout

Newer systems usually export comma-separated or other delimited files, with or without a header row:

account_number,check_number,amount,issue_date,payee,void
0012345678,10241,1250.00,10/15/2026,ACME Industrial Supply Inc.,N
0012345678,10242,487.75,10/15/2026,Riverside Utilities,N
0012345678,10198,200.00,10/09/2026,,Y

Delimited files are easier to read and less sensitive to exact positions. They bring their own problems: commas inside payee names need quoting, spreadsheet programs strip leading zeros from account numbers, and dates come out in whatever format the computer's regional settings prefer.

The errors that cause exceptions

• Decimal mistakes. A file with a decimal point loaded as implied cents, or the reverse, turns $1,250.00 into $12.50 or $125,000.00. Every check becomes an amount mismatch.
• Leading zeros lost. Account 0012345678 becomes 12345678 after a pass through a spreadsheet. The account isn't found, and the rows fail.
• Date format confusion. 10/09/2026 read as September 10 instead of October 9 creates false stale-date exceptions, or misses real ones.
• File sent late. Checks mailed before the file is sent can be cashed before the bank knows about them. That's especially likely when a payee deposits by mobile app the same day.
• Missing files. The file stops coming after a system change or staff turnover. Every check becomes "not in file".
• Duplicates and re-sends. A file sent twice shouldn't create two issue records for the same check. The system should reject or flag the duplicate.
• Voids never sent. A voided check that was never reported stays "outstanding" and will pay if it's later stolen and presented.

What a bank should look for in a system

Because every customer's file is different, the system the bank uses has to cope with many layouts, not just its own published one:

• Define a customer's layout once, delimited, fixed-width or Excel, and reuse it for every file.
• Build the layout from a sample file and preview the parsed result before saving it.
• Handle implied cents, separate cents columns, named date formats, void flags and leading zeros.
• Reject a file whose control totals don't add up, before anything is loaded.
• Report bad rows one by one, with the field at fault, instead of failing the whole file.
• Keep the original file exactly as received, as evidence of what the customer actually sent.
• Flag customers who haven't sent a file in a set number of days.

Issue files in OpenClear

OpenClear reads issue files in any delimited format, in Excel, and in customer-specific layouts defined under Settings → File layouts. A layout can be delimited (any delimiter, with or without a header, columns by name or position) or fixed-width (start and length per field, an optional record prefix, and header or trailer lines to skip). It handles implied cents, separate cents columns, named date formats such as MMDDYY and YYYYMMDD, and a void flag. The layout builder starts from a sample file and a library of common shapes, and previews the result before saving.

Files arrive by upload, by the JSON API, or through a watched drop folder. Each file is stored with its SHA-256 fingerprint and an ECDSA signature, and an upload can be backed out later if it was wrong. On the presentment side, the same layout builder reads the core's posted-check file: it can split the MICR on-us field into account and check number, skip lines that aren't check debits, leave out reversals, and refuse a file whose trailer count or total doesn't match its lines. OpenClear also reads X9.37 image cash letters and standard NACHA ACH files, and rejects any file whose control totals don't balance. See bulk file uploads in the docs.