Skip to content 
Electronic bank statement (EBS) processing turns a file from your bank into postings in S/4HANA: balances update, customer and vendor open items clear, and charges and interest land on the right accounts.
The import itself is the easy part. Where teams lose time is the post-processing — the items that import but don’t post. This post covers the flow end to end, the configuration pieces that matter most, and the three failure modes behind almost every stuck statement.
The formats, briefly
- MT940 — the SWIFT statement format, still the most common worldwide. Remittance detail sits in the
:86:field, which your interpretation and search strings have to mine. - camt.053 — the ISO 20022 XML successor, now standard across SEPA. References and charges sit in structured elements, and transactions carry ISO bank transaction codes instead of SWIFT codes.
- BAI2 — the US cash management format, built around three-digit type codes per transaction category.
All three run through the same import machinery; what changes is the mapping layer — how each bank’s transaction identifiers become SAP external transaction codes.
The flow, step by step
1. Import with FF_5. Transaction FF_5 (program RFEBKA00) reads the file, checks the account identification against your house bank accounts, verifies the statement number sequence and balances, and stores the statement as memo records.
2. Interpretation and posting. For each line, the external transaction code is translated through your configuration into a posting rule, and the interpretation algorithm searches the note-to-payee information for the open item the payment belongs to. Posting normally happens in two areas: the bank accounting posting (main bank GL to a clearing account) and the subledger posting that clears the customer, vendor, or GL open item.
3. Post-processing in FEBAN. Lines that don’t post — no rule found, no matching open item, an amount difference — wait in FEBAN, the post-processing worklist. There you correct the account assignment or posting rule, post with a difference where the bank deducted charges, and repost. The discipline that keeps FEBAN small: fix causes (a mapping entry, a search string), not individual items.
4. FF_6 and the Fiori apps. FF_6 prints/displays the imported statement in its original form — handy when reconciling what the bank sent against what SAP stored. S/4HANA also offers Fiori apps such as Manage Bank Statements over the same data; the classic FF_5/FEBAN flow remains fully relevant.
The configuration that matters
Three pieces decide whether statements post themselves or pile up:
- Global settings per format and account: the interpretation algorithm and posting behavior (post on import vs. memo records first) are set here — this is where “how automatic is this account” is actually decided.
- Account symbols and masking. Posting rules name account symbols, not GL accounts; at runtime the symbol resolves against the house bank account through masking. One rule set serves many accounts — and a wrong mask posts to the wrong account instead of erroring.
- External transaction codes → posting rules. Every code your bank sends (SWIFT, ISO, or BAI2) must map to a posting rule defining the accounts and posting type. Search strings — patterns matched against remittance text — sit on top of this and supply references or account assignments for recurring payers.
Where it breaks: the top three
1. Unassigned external transaction code. The statement imports; specific items never post. The bank sent a code — often a new charges or returns code — that isn’t mapped to a posting rule. Fix: map it from the bank’s actual code list, then reprocess in FEBAN.
2. camt.053 configured with MT940 habits. Match rates collapse after a format migration. References sit in structured XML elements, not the :86: text your search strings were written for, and identification uses ISO codes. Fix: rebuild the mapping and search strings against real camt.053 files.
3. The FEBAN backlog. Unmatched and short-paid items get parked instead of resolved, and month-end inherits the pile. Fix: a daily post-processing cadence, difference posting where the bank took charges, and converting every repeat item into a mapping or search-string fix.
Quick checklist
- Every external transaction code from the bank’s real code list mapped to a posting rule
- One real statement file per house bank account imported and posted in the test system
- Account-symbol masking verified for the main bank GL and each clearing account
- Search strings tested against historical remittance text — narrow, not greedy
- FEBAN post-processing assigned as a named daily task
Going further
EBS is a compact topic, and the Aumtech Solutions course treats it that way: a short, focused walkthrough of the configuration and processing, at a starter price.
- Free sample lesson: a full lesson is free to watch on the course page. SAP Electronic Bank Statements course
- Full course: SAP Electronic Bank Statements — $21, at aumtechsolutions.com/courses/sap-electronic-bank-statements
- Free Treasury Health Check: a short self-assessment for your treasury and payments setup, at aumtechsolutions.com/treasury-health-check
For the payments side of the same landscape, see the new SAP Advanced Payment Management and In-House Banking (APM + IHB) course.
