SAP's EBS tutorials stop at manual posting. The configuration is three layers deeper

Most SAP FICO walkthroughs of Electronic Bank Statement (EBS) processing show the same thing — a statement file, a posting run, and a screen full of matched line items. That's the output. Getting a bank's raw file to post itself against the right G/L and sub-ledger accounts, without a person clearing every line by hand, is a separate, Customizing-side job most of those videos never open.

What Electronic Bank Statement configuration actually covers

Per SAP's own Bank Accounting (FI-BL) documentation, the component is there to "handle accounting transactions that you process with your bank" — covering "the management of bank master data, cash balance management (check and bill of exchange management), and the creation and processing of incoming and outgoing payments," with country-specific manual and electronic payment procedures left fully configurable. Electronic Bank Statement (EBS) processing sits inside that: it's the mechanism that takes a bank's own statement file and turns each line into a posted document against the right account, without someone re-typing it.

Three configuration layers, not one

The gap most FICO walkthroughs leave is that "EBS setup" isn't a single screen — it's three separate pieces of configuration that all have to agree before a statement posts itself instead of landing in a suspense account.

Skip the house-bank or posting-rule layer and the statement still imports — it just doesn't post itself. Skip a required conversion and it doesn't parse in the first place. A missing posting-rule assignment for a transaction code is a common reason a statement "uploads but shows nothing to post": the file parsed fine, but nothing in Customizing told the system which account or algorithm to use for that specific code.

Video walkthrough by Himanshu Aggarwal — embedded with credit; the guide above is our own.

The DMEE step most walkthroughs skip entirely

The comment sections under most EBS videos ask for the same missing piece: what happens when the bank's file isn't in a format SAP already understands, and a posting-rule table alone can't fix that. That's the DME Engine's job, and it's a separate configuration surface from posting rules — SAP's own DME Engine documentation describes a program that "convert[s] incoming data medium exchange (DME) files to a format that the system can read and process," run from the SAP Easy Access menu under Accounting → Financial Accounting → Banks → Incomings → Bank Statement → Convert with DME Engine.

Before that program does anything useful, per the same documentation, two things have to already exist:

• A format tree built in the DME Engine that models the structure of the specific file your bank sends. SAP's documentation is explicit that incoming conversion currently supports one target only — "the DMEE supports conversion into MultiCash format only (tree type MCSH)" — so the format tree models your bank's source file, and MCSH is what it converts into.
• Optionally, a BAdI: File Conversion implementation — applying to every file of that tree type — or a narrower BAdI: File Modification scoped to one specific format tree, if the raw file needs adjusting before or after conversion. Both live in Customizing under Cross-Application Components → General Application Functions → Data Medium Exchange Engine → Business Add-Ins → Incoming Files.

Run correctly, the conversion program can hand its output straight to posting — SAP's documentation notes the system can "automatically call a processing program once it has generated" the converted MultiCash files, behaviour you implement in the BAdI, not a switch you flip. That chaining is exactly the piece a "here's the button to click" tutorial can't show, because it depends entirely on your bank's specific file layout — there's no generic screenshot for it. It's also, per SAP's own note on the conversion program, worth leaving the Generate Check Results indicator switched on (it's on by default): skip it and a file with structural errors still gets converted, just silently.

What a correctly posted bank line still doesn't answer

Get all three layers right and the outcome is genuinely useful: a bank statement line becomes a cleared, posted accounting document with no one re-keying it. That's a real automation, and it's the one most EBS content is built to show off. It answers one question — did this money move, and against which G/L or sub-ledger item — and it answers it well.

It doesn't answer a second, entirely separate question: is the GST input tax credit tied to that payment actually yours to claim. Matching a payment to a bank line says nothing about whether the underlying invoice is eligible under Input Tax Credit rules, or whether the supplier ever reported it. EBS posting rules and algorithms are matched to a vendor's open item in your books — not to a GSTIN, not to an invoice number in a return, and not to GSTR-2B. Rule 60(7) of the CGST Rules defines GSTR-2B as "an auto-generated statement containing the details of input tax credit". The rule says nothing about stability — GSTN's own IMS advisory does: a draft is generated on the 14th, the recipient's accept/reject/pending actions can change it until GSTR-3B is filed, and recomputation is mandatory if any action changes after the 14th. It is not a static export a posting-rule table can be pointed at (as of 4 September 2026).

It's also worth being precise about a second, narrower gap: an interpretation algorithm's job is to find the open item a bank line should clear — by invoice number, assignment number or reference field — not to independently verify that the underlying invoice is genuine or hasn't already been billed once. Two invoices from the same vendor for the same delivery, posted as two separate open items, will both clear happily against two separate bank lines; EBS has no duplicate-invoice check of its own — the control lives in the vendor master's duplicate-invoice flag and in invoice verification, upstream of any bank line.

On the bank side, that matching is Customizing you maintain by hand — one posting rule and one algorithm per external transaction code, per house bank, updated by a person whenever a bank changes a code or adds a new payment type. Doing the equivalent check on the GST side — is this specific invoice in your GSTR-2B, did the supplier actually file it, does the credit still hold — invoice by invoice, every time a bank line clears, is painful to do manually at any real volume. It's the same underlying problem the bank feed already solved on the accounting side, unsolved on the tax side: matching a mismatched, ever-changing external source against your own books without a person opening every line. The full reconciliation picture — and the same "matched payment isn't GST evidence" gap, worked through for Zoho Books instead — covers this beyond the bank leg alone.

What Recoup does with the SAP data once EBS has posted it

Recoup doesn't touch your EBS Customizing or your posting rules — that configuration, once it's right, is doing its job. Recoup picks up after: it reconciles your purchase register, exported from SAP, against GSTR-2B continuously, names the specific invoice and vendor GSTIN behind a gap rather than just the G/L line EBS already cleared, and flags where a payment that posted cleanly still sits on an invoice the supplier hasn't reported. The bank side and the GST side were never the same reconciliation — they just both start from a bank statement.

Related guides