Every SAP team knows the two numbers. There is the auto-posting rate quoted after go-live, and there is the FEBAN list that the same two people work through every morning. Statements import fine — the earlier post in this series covered the FF_5/FF_6 processing side — yet a stubborn slice of statement lines never clears itself.
That slice is rarely an import problem. A statement line has to survive two decisions before it posts untouched: a posting rule decides what accounting it should produce, and a matching rule decides which open item, if any, it settles. Lines fail on one of those two decisions, and they fail for a short list of repeatable reasons.
Decision one: the posting rule
Each external transaction code on the statement — the bank’s own code for a cheque, a transfer fee, an interest credit — is mapped to a posting rule. The rule carries the posting area logic: which accounts are debited and credited, whether the line posts to a bank clearing account first or directly against a customer or vendor, and what document type and posting keys are used.
The classic failures are mundane. A bank introduces a new transaction code or changes a code’s meaning, and the unmapped code posts to a fallback — or does not post at all. A fee the rule was written for splits into two fee types, and one half lands in the wrong account every single day, small enough that nobody investigates for a quarter. Posting rules are configuration written once against a bank format that keeps evolving; the mapping needs the same maintenance discipline as the bank connection itself.
Decision two: matching against open items
For lines that should clear an open item — a customer payment against an invoice, an outgoing payment against the payment run’s clearing entry — the system searches using the references in the statement’s note-to-payee text and the configured search rules: document number, reference document, amount and value date windows, and interpretation algorithms that decide what a found number actually is.
Matching fails in both directions. Too strict, and a payment that differs by a bank charge or a truncated reference sits unmatched although a human spots the pair instantly. Too loose, and the statement clears the wrong item automatically — which is worse, because a false clear does not wait in FEBAN asking for help; it becomes accounting that someone has to unpick later. The working target is narrow rules that match only what you would clear yourself, every time.
FEBAN is the exception queue — run it like one
What survives both decisions lands in FEBAN, the manual reprocessing transaction, and how a team handles FEBAN determines whether the auto-posting rate improves or fossilises. A workable routine:
- Work it daily, in order of value date. Exceptions age badly; a line from three weeks ago takes three times as long to explain.
- Classify every exception before fixing it. Wrong posting rule, missing match, genuinely new business event, or bank error. The class decides the fix — a human decision in FEBAN, or a configuration change that stops the next fifty occurrences.
- Post or clear from within FEBAN rather than journaling around it, so the statement line and its accounting stay linked and the audit trail survives.
- Count the repeats. If the same bank, code, or counterparty produces an exception every week, that is a configuration ticket, not a reprocessing habit. The goal is a FEBAN list that shrinks to genuinely new events.
The teams with high auto-posting rates are not the ones with the cleverest rules. They are the ones who read their exception queue as a list of configuration defects and fix the causes in order.
Where it usually hurts
- Bank transaction codes mapped once at go-live and never revisited after the bank changes its statement format
- Posting rules that send every “unidentified” line to one suspense account, where it rests unexamined
- Matching rules loosened to raise the rate, trading manual work for silent mis-clearings
- FEBAN treated as one person’s morning chore instead of the feedback loop for the whole EBS setup
Going further
Aumtech Solutions’ course SAP Electronic Bank Statement Training is a short, focused starter on this material — posting rules, matching and search rules, and disciplined FEBAN reprocessing — for $21: https://www.aumtechsolutions.com/courses/sap-electronic-bank-statements/
Not sure where your own statement processing stands? The free SAP Treasury Health Check scores your processes across treasury, payments, and bank statements in about 20 minutes: https://www.aumtechsolutions.com/treasury-health-check/