F-28 — Post Incoming Customer Payments and Clear Items
F-28 posts a manually entered incoming customer payment and clears it against open AR items in the same transaction. The header screen captures the bank/cash account and amount; a second screen lists the customer's open items for selection. Most problems trace back to a mismatch between the header amount and the total of items selected on that second screen.
This page covers F-28, the manual incoming payment posting and clearing transaction in FI-AR. It focuses on the two-screen entry logic, the difference-handling decision (partial vs residual), and the reversal chain that trips up consultants who forget clearing has to be undone before the document itself can be reversed.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,143 words
What it does
F-28 records a customer's incoming payment (bank receipt, check, wire) and simultaneously clears one or more open AR line items against it, producing a single financial document that both debits the bank/cash GL account and closes the customer's receivable. The structural fact that explains most user confusion is that it is a two-stage screen: header data (bank account, amount, value date, currency) is entered first, then a separate 'process open items' screen is where actual matching happens. The header amount and the sum of selected items must reconcile exactly, or the system forces a decision — partial payment, residual item, or write-off — before it will let the document post.
When it is used
F-28 is reached for whenever a customer payment arrives outside an automated channel: a check handed to the cashier, a wire that didn't match during bank statement processing, or a manual correction after lockbox failed to auto-clear. It sits at the tail end of the order-to-cash cycle, after invoice posting (FB70/F-22 style entries) and before period close. Consultants prefer bank statement processing or an EBS/lockbox program when volumes are high and remittance data is clean; F-28 is the fallback when human judgment is needed — deciding which invoice a partial payment applies to, or how to treat a small underpayment. It is the direct counterpart to F-53 for outgoing (vendor) payments.
How to use it
- Enter document date, posting date, and currency on the header screen
- Enter the bank/cash GL account and the payment amount received
- Enter the customer account number and account type
- Click 'process open items' to load the customer's open receivables
- Select (activate) the items being paid; deselect items not covered
- If the selected total does not match the header amount, choose partial payment, residual item, or write-off to absorb the difference
- Review the difference posting and cash discount calculated, then save
Key fields
- BKPF - the payment document header (company code, document number, posting date, document type)
- BSEG - all line items of the payment document, including the bank/cash debit line and the customer clearing line, carrying the clearing document reference once posted
- BSID - open customer items, read during item selection and updated to remove the item once cleared
- BSAD - cleared customer items, where the paid invoice lands after clearing, carrying AUGBL (clearing document) and AUGDT (clearing date)
How to prove it in the data
Pull BSAD filtered by BUKRS and KUNNR for the customer in question and check AUGBL and AUGDT to identify the clearing document and date. Cross-reference that AUGBL number against BKPF to pull up the F-28 payment document itself, and against BSEG (same BELNR) to see the bank/cash debit line and the customer credit line side by side. If the item is still open rather than cleared, it will still be sitting in BSID with no AUGBL populated — that is the fastest way to confirm a payment was entered but never actually assigned to the invoice.
ECC vs S/4HANA
F-28 still runs unchanged on S/4HANA; there is no hard replacement transaction. Fiori apps built around customer line item management and incoming payment posting cover the same function with a modern UI and are the preferred entry point in greenfield S/4HANA builds, but F-28 remains available for consultants who need the classic two-screen flow. Underneath, BSID and BSAD are now compatibility views generated from the universal journal (ACDOCA) rather than physical tables, though queries against them behave the same way for diagnostic purposes.
Common pitfalls
- Unassigned difference: the header amount does not equal the sum of selected items and the user does not resolve it, so the system either blocks posting or forces a difference posting the user did not intend. Check the tolerance group assigned to the customer or the posting user — differences within tolerance auto-post as cash discount or a small gain/loss; differences outside tolerance require explicit residual/partial handling.
- Partial payment vs residual item confusion: a partial payment leaves the original invoice open in full and creates a new open item for the payment amount, so the customer now shows two open items instead of one reduced item. A residual item closes the original invoice and opens a new receivable for the unpaid balance. Consultants often pick the wrong one and then cannot understand why FBL1N shows an extra line.
- Reversal without resetting clearing first: FB08 will refuse to reverse an F-28 document that has already cleared items, because the clearing status has to be undone first with FBRA. Attempting FB08 directly on a cleared payment document is the most common dead end reported as 'the document won't reverse'.
- Cash discount not calculated or wrong amount: usually traces back to a missing or incorrect payment terms key on the customer master or on the invoice item itself, or the baseline date used for discount eligibility being outside the discount window.
- Foreign currency exchange differences: when the payment currency differs from the invoice currency, a realized exchange rate gain/loss line appears automatically; if the posted GL account for that gain/loss looks wrong, the automatic account determination configuration for exchange differences is the place to check, not the F-28 entry itself.
- Blocked or locked account: posting fails outright if the customer account is blocked for posting or the GL account for cash/bank is locked; this shows as an authorization or account-status error rather than a clearing error and should not be mistaken for a data problem.
Whose problem this is
This is an FI/AR functional problem in almost every case — clearing logic, tolerance groups, and payment terms are configuration and master data decisions, not code. Basis involvement is limited to account locks or authorization failures. A good handover includes the customer number, the payment document number, the invoice(s) it was meant to clear, the exact error or unexpected posting, and whether the document has already been cleared or reversed.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/f-28ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.