Positive Pay in SAP: Check Issue Files, FCHX and Voids

Positive pay is a bank service that checks every presented check against the list of checks the company actually issued. In SAP, that list comes from the check register (table PAYR) and is written by the check extract, transaction FCHX (report RFCHKE00) on-premise or the Create Positive Pay Files app in S/4HANA Cloud. Any presented check that isn't on the list, or doesn't match it on number and amount (and payee name, with payee positive pay), becomes an exception, and the company decides whether the bank pays or returns it. The service is only as good as the issue file, which means only as good as the SAP data and timing behind it, voids included.

This page covers the SAP side end to end: where check data lives, how the extract works, how voids and encashments flow, and how check positive pay relates to the ACH controls US banks sell alongside it. The broader fraud picture is in payment fraud prevention in treasury. This page is about making one specific control work.

How positive pay works at the bank

The bank-side mechanics are common across US banks, though every detail below is set per bank agreement:

• The issue file. The company sends the bank its issued checks, at minimum check number, amount and issue date, and with payee positive pay also the payee name. Banks accept fixed-length, delimited or spreadsheet uploads, each to their own layout.
• Matching and exceptions. Presented checks are matched against the issue file. A check that is not on the file, or doesn't match it, is presented to the company as an exception.
• The decision and the default. The company decides pay or return for each exception before a daily cutoff. Anything not decided gets the default decision you chose at enrolment. Return is the protective default. Pay as a default removes most of the protection, because an exception nobody looks at gets paid.

The SAP job is to make sure the issue file is complete, on time and current. A late or incomplete file turns every legitimate check into an exception, the exception list turns into a rubber-stamp exercise, and then the control stops working.

Where the check data lives: PAYR

Every check SAP creates, whether from the F110 payment run, a manual check or payroll, gets an entry in PAYR, the payment medium file table, which serves as the check register. The fields that matter for positive pay:

Check lots (FCHI) define the number ranges. The check register (FCHN) displays PAYR, and the Fiori app Manage Outgoing Checks (F1578) covers displaying, creating, voiding, cashing and reissuing checks in S/4HANA.

The extract: FCHX and Create Positive Pay Files

FCHX reads PAYR for the selected company code and house bank accounts, writes the check details to a file, and updates the extract date and time on each check it includes. That stamp is what makes the process incremental. SAP's documentation for the Cloud app describes the selection option that relies on it: include only checks not yet extracted, which covers both new checks and checks that were extracted before but have since changed, for example voided. The same app can create files for checks from Payroll Accounting or from Financial Accounting, which matters when payroll checks run from the same bank account.

Three practical points:

• The standard layout is rarely the bank's layout. The classic extract writes a standard header-and-item structure, and banks each specify their own format. S/4HANA Cloud delivers the payment medium format US_POSIPAY (a fixed-width text file) and lets you define your own. On-premise, the usual route is a payment medium format built with DMEE rather than a modified extract program.
• A custom extract must keep the stamp. If you replace the standard program, it has to write EXTRD and EXTRT back to PAYR. If it doesn't, the "new or changed" logic breaks and the next file either repeats or misses checks.
• Automate it and deliver it like any bank file. S/4HANA Cloud has a job template (Creation of Positive Pay Files), and SAP documents an asynchronous outbound service, Positive Pay File - Send, for transmission. When the file goes through SAP Multi-Bank Connectivity, check the encoding: KBA 3780893 records Cloud positive pay files defaulting to UTF-16 instead of UTF-8 when MBC is selected in the payment method. That is a mismatch many bank parsers will reject.

"

Positive pay protects you from the checks you didn't write. It only works if the bank gets every check you did write, and every one you cancelled, before the cutoff.

Voids: the part that fails quietly

A voided check that the bank doesn't know about is a valid instrument. If it turns up, whether stolen from the mail or deposited twice, the bank has no reason to stop it. So void handling is the core of positive pay, not an edge case.

Void reason codes are defined in Customizing for Accounts Receivable and Accounts Payable, and the void writes date, reason and user into PAYR. The design rules that follow:

• Extract after voiding, before the bank's cutoff. A same-day void has to be in that day's file. Schedule the extract after the day's check printing and void activity, not before it.
• Don't delete what the bank needs to see. FCHE deletes voided checks and FCHD deletes payment-run check information. Both are housekeeping transactions, so restrict them and never run them before the void has been extracted.
• Checks written outside SAP. A handwritten emergency check has no PAYR entry, so it will arrive at the bank as an exception. Either record it in SAP as a manual check or accept that someone has to recognise it in the exception list.

Closing the loop: encashment and the statement

When the bank statement reports a paid check, EBS clears it through the check interpretation algorithms (011, 012, 013, as in the EBS guide) and sets the encashment date PAYR-BANCD. Your outstanding-checks list depends on that field. The catch is on the manual path: KBA 3466455 covers the encashment date not being updated when a check is cleared manually in post-processing instead of by the algorithm. Anyone clearing checks in bank statement post-processing needs to know whether their clearing path updates the field, or the outstanding list slowly drifts from the bank's paid file.

Check positive pay versus ACH controls

US banks usually sell check positive pay together with ACH controls, and the controls get confused because they share a name:

The practical difference for an SAP team: check positive pay is an interface you build and monitor, while ACH blocks and filters are bank-side master data. They don't live in SAP, but they are standing payment data all the same. Changes to the allowed-originator list deserve the same segregation of duties and dual control as changes to a vendor's bank details, because an unauthorised addition to that list works just like a redirected payment.

What I would put in the control description

The control only works if the operating detail is written down: which accounts are enrolled; the default decision (return); who reviews exceptions and their deputy; the extract schedule relative to check printing and the bank cutoff; a daily reconciliation of the file's check count and total to the register; restricted access to FCHX, FCHE and FCHD; and a monitored transmission, treated as an interface like any other in the interface monitoring set. None of it is complicated. It fails when one of those pieces is missing.

What I couldn't verify, and left out

• Bank liability rules. How liability for a paid fraudulent check shifts with and without positive pay depends on your bank agreement and the law that applies to it. It is not something to generalise on a systems page.
• Cutoff times and fees. They differ by bank. The ones in circulation are specific to one bank's product.
• Payroll-side positive pay details. Payroll checks share PAYR and the extract, but payroll check processing has its own transactions that this page doesn't cover.

See also bank communication management in SAP, SAP payment approval workflow and BAI2 file format.