What is the difference between posting area 1 and posting area 2 in SAP EBS?

Posting area 1 holds the posting specifications for G/L and bank account postings; posting area 2 holds the specifications for subledger postings. Each posting rule carries one or both, depending on what the transaction needs — SAP's own example is that a check credit memo needs only posting area 1, because the customer item was already cleared when the check was deposited, while an incoming bank transfer needs posting area 2 as well, so the system can find the customer and clear the open item. In practice, area 1 is where cash hits the bank and clearing accounts, and area 2 is where the receivable or payable actually closes.

Where do you assign an interpretation algorithm to a posting rule?

In the same configuration activity where external transaction codes are mapped: Assign External Transactions to Posting Rules, inside Make Global Settings for the Electronic Bank Statement in Customizing for Bank Accounting. For each external transaction code — differentiated by a plus sign for cash receipts and a minus sign for disbursements — you enter the posting rule and the interpretation algorithm. The algorithm setting determines whether, and with which logic, the system searches the note to payee lines of that transaction for clearing information.

Why does interpretation algorithm 001 find no documents?

Usually because of the number intervals, not the algorithm. Algorithm 001 interprets note-to-payee values as document or reference document numbers, but it checks them against the BELNR and XBLNR number ranges entered on the selection screen when the statement is imported — if those intervals are missing or wrong, nothing matches. The second documented trap is leading zeros: if the reference was stored in the system with leading zeros, the statement must deliver it with those zeros, in exactly the same form and length, or the item will not be found.

When should you use a search string instead of an interpretation algorithm in SAP EBS?

When the reference information arrives changed. Interpretation algorithms need the document number transmitted unchanged; SAP's documentation is explicit that if characters have been added or removed, the algorithms cannot find the document. Search strings supplement the algorithms for exactly that case — customers who drop leading digits, split numbers with spaces or periods, or wrap the reference in other text. You define a search string with pattern characters to recognise the mangled number, a mapping string to reconstruct the real one, and you can test and simulate the definitions against imported statements before relying on them.

SAP EBS Posting Rules and Interpretation Algorithms

Every SAP electronic bank statement implementation is, underneath, the same four configuration objects: external transaction codes, posting rules with their posting specifications, account symbols, and interpretation algorithms — plus search strings for when the algorithms aren't enough. The EBS process article covers what the pipeline does — import, interpret, post, post-process; this page is its configuration-level sibling, the one you want open when you're actually in the IMG. And it follows the house method: search for this topic and you'll find forum threads listing algorithm numbers nobody can source, so every config object, algorithm number and behaviour below is checked against SAP's own documentation, and the ones I couldn't verify are named at the end rather than silently included.

The chain, end to end

SAP's documentation describes the determination as a search sequence, and it's worth memorising because every "why did it post there?" investigation walks it backwards:

From the bank key and bank account on the statement, the system finds the transaction type in the Customizing table.
From the transaction type plus the external transaction code — the bank's business transaction code on the statement line — it determines the posting rule key.
From the posting rule, it reads the posting specifications and the account determination you configured.

Separately, the interpretation algorithm assigned to that external transaction decides how the note to payee is searched for clearing information — document numbers, reference numbers, check numbers. Posting and clearing are different problems, and the config treats them as such.

All of it lives in one place: Customizing for Bank Accounting, under Business Transactions → Payment Transactions → Electronic Bank Statement → Make Global Settings for the Electronic Bank Statement. Per SAP's Defining Posting Rules page, that activity is where you create the account symbols, define the account determination per symbol, and create the posting specifications for the two posting areas.

External transaction codes: what the bank sends

SAP defines external transactions — also called business transaction codes — as bank-specific codes for business transactions, each representing a different type of payment. The bank puts them on the statement; the system uses them to identify what the line is, and converts them to its own internal posting rules. SAP's documented examples: 020 transfer order, 051 transfer credit memo, 052 recurring entry credit memo, 072 bill of exchange presentation, 206 foreign bank transfer. What actually arrives depends on the format — the code sits in the statement line of an MT940 or a camt.053 — and, more importantly, on the bank's own dialect, which is why the mapping is maintained per transaction type rather than globally.

Two details from the assignment activity that carry real weight:

The +/- sign. External codes are differentiated by sign: + marks a cash receipt, - a disbursement. Plenty of banks reuse one code for both directions, and this is the mechanism that splits them into different posting rules.
The interpretation algorithm is assigned here too. The mapping row isn't just code → rule; it's code → rule → algorithm. Choosing the algorithm per external transaction is the design decision, not an afterthought.

Posting rules and the two posting areas

A posting rule specifies how a business transaction from the statement posts in your system, and each rule can carry two sets of posting specifications:

Posting area 1 — G/L account (or bank account) postings.
Posting area 2 — subledger postings.

You define one or both, depending on what the transaction needs. SAP's own example is the cleanest explanation I know: a check credit memo needs only posting area 1, because the customer item was cleared when the check was deposited; an incoming bank transfer needs posting area 2 as well, so the system can clear the customer's open item. The documentation's process description makes the same point as a two-level posting: cash receipt to a clearing account first (the bank posting), then locate the customer and clear the item (the subledger posting).

A posting specification itself is small: posting key and account symbol for one or two line items — a debit and a credit entry. That's it. The complexity of an EBS implementation is not in any single rule; it's in having a correct rule for everything your banks actually send.

Account symbols: the indirection that makes it portable

Posting specifications never name G/L accounts directly — they name account symbols, and the system replaces the symbol with the right account at posting time. SAP's example is an account symbol BANK standing in for account 113100. You define the symbols yourself in Customizing and define account determination rules for each.

The prerequisite chain matters more than it looks: account symbols resolve against the house bank setup, so every account you hold at a house bank needs a G/L account in the system, and the currency key in that G/L account's master record must match the currency of the actual bank account. SAP's documentation carries an explicit caution here — if a house bank account has no G/L account, the system cannot post the electronic statement at all. I've watched that exact miss eat the first day of more than one EBS test cycle: the rules were fine, the symbols were fine, and one new bank account had no G/L account behind it.

Interpretation algorithms: the documented list

Posting answers "which accounts"; interpretation answers "which open item". The note to payee fields of the statement carry document numbers, reference document numbers or check numbers, and the interpretation algorithm determines how the system reads them. One warning from SAP's documentation before the list, because it explains half of all interpretation failures: the information must already be known to the system in exactly the same form and with exactly the same number of characters — leading zeros included. Bank statement data that is almost the reference number finds nothing.

These are the algorithms SAP's documentation describes, with the documented behaviour. Numbers you may have seen elsewhere that are not in this table are covered in the exclusions section — I only print what I could verify.

Algorithm	SAP's name	Documented behaviour
000	No interpretation	Standard interpretation off — for when you use your own algorithms via functional enhancements (user exits) instead
001	Standard algorithm	Reads note-to-payee values as document or reference document numbers, checks them against the BELNR/XBLNR intervals entered at statement import, and only then searches for items to clear
011	Outgoing check, check number not identical to document number	For pre-numbered checks: the bank returns the check number, the algorithm finds the document number from it
012	Outgoing check, check number identical to document number	For checks printed without pre-printed numbers, where the document number serves as check number; needs the document number ranges at import, like 001
013	Outgoing check, identical or not identical	Finds the check number per algorithm 011 or 012, whichever applies
015	Clearing transaction: selection via assignment number	Selects items to clear by assignment number if the rule permits clearing; otherwise writes the bank reference into the assignment of the posting on account, for later automatic clearing via report SAPF123W
019	DME administration reference number	For statement lines confirming a payment run total: finds the DME reference in the note to payee and uses it to find and clear all line items of that payment medium
020	Document number search	Like 001, but interprets note-to-payee content as document numbers only
021	Reference document number search	Like 001, but reference document numbers only
022	BZÜ method with document number (Germany)	Reads the 13-digit BZÜ coding-line number, cuts the check digit, interprets the rest right-aligned as a document number
023	BZÜ method with reference document number (Germany)	Interprets the BZÜ number, including its check digit, as a reference document number
026	Reference number with leading zeros	For ten-digit references arriving without leading zeros: reads candidates like 021, pads to ten digits with leading zeros, then compares
027	Reference number TITO	Searches for the payment reference of the Finnish TITO statement format
028	Reference number per MultiCash conversion	Same as 027 for files imported in MultiCash format, using the BELNR number range
029	Payment order number	Searches by payment order number, using the XBELNR number range
030	Brazil	For Brazilian statements: searches for document number, fiscal year and line item number within the accounting document
031	Document number search, customer number in line item	Works like 020, plus: can add customer bank details from the statement to master data, and is the algorithm under the payment advice notes the import creates when it can't clear everything — items for several partners only auto-assign correctly with 031
120	Document number search with no check	Searches by document number without checking the document exists — only that it's inside the import number range; documented as the way to clear open items in a different bank company code
121	Reference document number search with no check	The 120 behaviour for reference document numbers only

A few reality notes on the ones that generate the support tickets:

001 (and 012, 020, 021) fail quietly when nobody fills the number ranges. The intervals for document and reference document numbers are entered on the import selection screen — a runtime input, not a config setting. An import variant without them turns the standard algorithm into a no-op, and the symptom is "EBS posts but never clears".
015 is the pragmatic fallback when the statement carries no usable document reference: post on account with the bank reference in the assignment field, clear later via SAPF123W. The documented catch is that the assignment is a text field fed from the bank reference or the start of the note to payee — if that field doesn't carry what you think it carries, check before building a process on it. SAP's documented escape is the customer exit that fills the check number field (FEBEP-CHECT) — one of the FEBEP fields this whole machinery reads and writes.
031 over 021 for mixed remittances. Where one statement line pays documents of several business partners, SAP documents that only 031 assigns the payment advice items to the right partners automatically; with 021 you correct them by hand.
The set still grows, by localization. SAP S/4HANA Cloud Public Edition 2508 added algorithm 805, which filters open bank statement items by Polish KSeF reference numbers from the memo line — assigned in the same Assign External Transactions step as everything else. If you work in a localized environment, check the release notes for your country before concluding the standard set is all there is.

Search strings: the escape hatch

The algorithms all share one documented assumption: the reference arrives unchanged. SAP's documentation is blunt about the failure mode — if figures or characters have been added or removed from the document number, the algorithms cannot find it, and the transaction goes to manual post-processing. Its examples are exactly what you see in real statements: customers dropping a constant leading 18000 from invoice numbers, splitting numbers with spaces, periods or dashes (540 6423, 6.032946, 60-67132), or burying the reference in 001*0050*0000851333.

Search strings supplement the interpretation algorithms for that case, without programming. Three parts, per the documentation:

The search string — a pattern that recognises the mangled reference. It can be any length and mixes literal characters with pattern characters: | for alternation, ( ) for grouping, + and * for repetition, ? as a single-character wildcard, # for any digit 0–9, \ to escape a special character, ^ and $ for start and end of line.
The mapping string — a character-by-character transformation that strips or replaces the excess, reconstructing the actual document number from what the pattern matched. If nothing needs replacing, search and mapping strings are identical, and the system proposes the search string as the default mapping.
Test and simulate. You can test an individual search/mapping string against a value, and — the part worth building into your cutover plan — simulate a whole set of definitions against statement imports, comparing what posted automatically before and after. That turns search-string tuning from folklore into a measurable loop: define, simulate, adjust, until items that fell out post automatically.

The Customizing activities SAP names for this are Define Search String for Document Numbers and Simulate Document Number Search Using Strings, in Customizing for Bank Accounting. My working rule: exhaust the standard algorithms first, reach for search strings when the diagnosis is specifically "the reference is there but deformed" — and treat every search string as a small program that deserves the simulation step before it goes anywhere near production.

What I couldn't verify, and left out

Same discipline as the rest of this SAP treasury guide — the gaps are named, not papered over:

Algorithms 040 and 041. SAP's page references algorithm 040 without describing it, and describes 041 ("Treasury: Search for loan, then standard search") only as the reverse order of 040. A description defined relative to an undescribed sibling isn't something I'll print as behaviour, so both stay off the table above.
Forum-circulated algorithm numbers. Numbers you'll find in threads and slide decks that are not on SAP's Interpretation Algorithms page are not listed here. That's not a claim they never existed in some release — only that SAP's current documentation, which is my bar, doesn't describe them.
Search strings targeting other fields. Consultant lore says search strings can also derive posting rules, cost centers and other fields from note-to-payee text. The SAP Help pages I could fetch document the document-number string search; I couldn't verify the broader target-field mechanism there, so it's excluded rather than asserted.
Configuration transaction codes. The IMG activity names above are documented; specific config tcodes for them are not printed because the pages I verified don't name them. The runtime codes — FF.5 to import, FEBA_BANK_STATEMENT to post-process — are covered in the transaction codes reference.
S/4HANA versus ECC differences. The interpretation algorithms documentation in the S/4HANA Financial Operations set is the same document SAP published for SAP ERP, and I found no documented behavioural difference in these config objects between the two — the documented movement is additive and localized, like Cloud's algorithm 805. Absence of documented difference isn't proof of identical behaviour in your release; it's the reason the scope note on this page says verify against yours.

The config objects on this page are small and old and stable — a mapping table, two posting areas, a list of algorithms, a pattern matcher. What makes EBS configuration hard was never the objects; it's that the statement data they run against is someone else's export. Which is why the two ends of the chain deserve most of your attention: the external-code mapping at the front, against what your banks actually send, and the interpretation settings at the back, against how your customers actually write reference numbers. Get those two honest, and the middle of the chain mostly just works.