FEBAN: Bank Statement Post-Processing in SAP

FEBAN is SAP's GUI transaction for bank statement post-processing: it lists the electronic bank statement items the import could not fully post or clear and lets someone finish them by changing the posting rule, adding the account or clearing information, and posting. Its newer sibling is FEB_BSPROC, and in S/4HANA the Fiori app Reprocess Bank Statement Items (F1520) does the same job. They all work the same queue, and the queue is a symptom. Every item in it is a configuration gap or a data problem that will come back tomorrow unless someone fixes the cause as well as the item.

This page is the working companion to the SAP electronic bank statement guide, which covers the configuration chain. This one starts where that chain drops an item: why it dropped, how to reprocess it, and how to stop the same item dropping again.

Five names for one queue

The naming confuses people, so start there:

SAP's support content lists FEBA_BANK_STATEMENT, FEB_BSPROC, FEBA and FEBAN together as the post-processing transactions. The practical warning is that they are not interchangeable views of one thing. SAP publishes a page on the differences between FEB_BSPROC and the Fiori app, and its knowledge base has articles on items that show in FEBAN or FEB_BSPROC but not in F1520 (KBA 3364532), and on open-item allocation that happens automatically in FEB_BSPROC but needs a manual step in F1520 (KBA 3568048). Pick one tool per team and learn how it behaves. When two people work the same statement in different tools, expect to spend time reconciling the tools instead of the bank account.

Why items stay open

An item reaches post-processing because one of the two posting areas did not complete. Posting area 1 books the bank side (bank account and clearing account). Posting area 2 does the subledger side: it finds the customer or supplier and clears the open item. The statement line-item table FEBEP carries a status for each (the fields VB1OK and VB2OK), and adding both to your FEBAN layout is the fastest diagnostic you have. Area 1 done and area 2 not done means the cash is booked but nothing is cleared, which is the most common state in the queue.

The causes, in the order I would check them:

The algorithm and search-string mechanics behind rows three and four are covered in detail in the EBS guide. For most items that pile up in the queue, the fix is in the import variant or the search strings, not in the posting rules.

Reprocessing an item

In FEBAN the working pattern is: select the statement and item, look at the note to payee, correct what is wrong on the item (posting rule, account, the reference or clearing criteria), and post. FEB_BSPROC adds an editable note to payee. The Fiori app lets you assign the payment to a customer, supplier or G/L account and clear open items. There you can also mark an item as reprocessed with a reason, which is the option to use when the item needs no posting but should leave the queue.

Three details save time:

• Foreground, not background. SAP's support content and KBA 2637795 discuss posting from the post-processing transactions in foreground or background, and the recommendation is foreground. When a posting fails in foreground you see why. In background you find out later.
• Manual clearing does not always do what the automatic path does. KBA 3466455 is the clearest example: the check encashment date (PAYR-BANCD), which the check algorithms 011–013 set when they clear a check automatically, is not updated when a check's payment document is cleared manually in post-processing. How you clear checks decides whether your outstanding-checks list and your positive pay reconciliation agree with the bank.
• Reversal and re-post is a normal operation. A wrongly posted item can be reversed and reprocessed with the same functions as the original posting. Treat it as a correction with an audit trail, not a failure to hide.

"

The post-processing queue is where the EBS configuration shows its gaps. Clearing an item fixes today's statement. Recording why it failed is what fixes next week's.

Shrinking the queue

Staffing the queue works until volume grows. The durable approach is to treat the queue as a defect list and work it by cause:

1. Classify before you clear. Pull the open items (FEBKO for statement headers, FEBEP for items) and group them by external transaction code and bank. A handful of codes usually accounts for most of the volume, and each one points to a single configuration fix.
2. Map what the banks actually send. Missing external-code assignments are the cheapest fix, since one row in Customizing removes a daily manual posting.
3. Tune search strings with the simulation. SAP provides a simulation of document-number search strings against imported statements. Use it before transporting a new string.
4. Turn repeated decisions into processing rules. Manage Processing Rules - For Bank Statements (F3555) defines conditions and actions (G/L postings, AP/AR postings, clearing), which the Reprocess Bank Statement Items app can apply. SAP ties the automatic mode, where rules run in the background during import, to its Cash Application integration, so check your scope before designing around it.
5. Enrich at import when the pattern is yours. The BAdI FIEB_CHANGE_BS_DATA runs during import and again during post-processing, including FEB_BSPROC and F1520. It is the place for company-specific logic that no standard algorithm will ever know, such as deriving a customer from a virtual account number. Keep it small and documented.
6. Fix references upstream. Remittance discipline with customers and virtual account structures improve auto-clear more than any post-processing tool can.

Measure the result as a rate, not a headcount: the share of items that post and clear without a person, per bank and per transaction code. That rate is straight-through processing applied to bank statements. When it drops, a bank changed something, and the queue will show it before anyone tells you.

Where AI fits in the queue

The residue that survives all six steps is exactly the part that rules handle badly: free-text remittance, payments for several invoices with deductions, references that are nearly right. SAP's own answer is its Cash Application service, whose automatic bank statement reprocessing proposes matches for these items. The design question for any AI step here is the one the bank reconciliation teardown works through: the model proposes, deterministic rules check amount and tolerance, and a named person decides the clearing on the residue. The exception path should be designed before the model is chosen, and the treasury exception management page covers the operating side: owners, ageing and escalation.

What I couldn't verify, and left out

• Whether FEBAN is formally deprecated. Some sources say FEB_BSPROC replaces FEBAN from a given release. I found SAP documentation for FEB_BSPROC but no SAP statement retiring FEBAN, so this page describes both as available on-premise.
• The exact field-level differences between FEB_BSPROC and F1520. SAP publishes a comparison page, but I could only confirm the individual differences named in the KBAs above.
• Scope-item numbers for automatic processing rules. They differ by edition and release. Check your own scoping.

See also bank statement formats: MT940 vs camt.053 vs BAI2, SAP cash management in S/4HANA and SAP treasury Fiori apps.