...

Bank statement automation in SAP: posting rules, matching rules, and the FEBAN pile

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:

  1. Work it daily, in order of value date. Exceptions age badly; a line from three weeks ago takes three times as long to explain.
  2. 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.
  3. 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.
  4. 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/

Leave a Comment

Your email address will not be published. Required fields are marked *

Seraphinite AcceleratorOptimized by Seraphinite Accelerator
Turns on site high speed to be attractive for people and search engines.