Skip to Content
Technical Articles

All you need to know about Electronic Bank Statement – CAMT 054 format

Most of the articles on EBS talk about step by step configuration guide. They talk about concepts & end to end process very rarely. I hope we all agree that step by step configuration guide is quite easy to follow, but the main challenge is to understand the concept. If we understand the concept, it becomes easier for us to implement the process in live systems. In this blog, I have tried to explain how the EBS process works in SAP. At least I found it hard to implement when I started working on EBS in my project. I wish my blog makes EBS process easy to my SAP colleagues across the globe.

This is a techno-functional blog, prepared to help both technical and functional consultants.

What is EBS?

Electronic Bank Statement is provided to the account holders in standard formats, e.g. CAMT, MT940, BAI2 etc. As a part of Payment Transaction processing, EBS can be imported and posted in SAP for reconciliation.

 

What is CAMT 054 format?

The camt.054 format provides you with the required information on all transactions entered on your account. This includes the information on SEPA transactions in standard Euro payments. The reports in camt.054 allow you to carry out the processing of individual transactions entered on your account as a total figure. The camt.054 is an alternative to MT900 Confirmation Debit, and MT910 Confirmation Credit.

 

Understanding the file format and how to map it with SAP tables:

Almost every bank that supports CAMT 054 provides a file specification explaining the file structure and the information it can hold. You can find a sample in the below link.

https://online.swedbank.se/ConditionsEarchive/download?bankid=1111&id=WEBDOC-PRODE23208726

CAMT 054 is an XML file with complex structure, so it is almost impossible to understand the file content just going through the file.

Worried!!!??? Don’t be.

SAP has already provided a transformation for this file format. So, SAP program can automatically transform the file content and load it in SAP tables. But yes, for that we need to complete basic EBS settings. If you want to review how the file will look like after transformation, follow the below steps.

Step 1:

Execute the following node in SPRO and check if the transformation exists for CAMT 054. It should be there.

 

Step 2:

  • Go to transaction STRANS and enter the transformation FIEB_CAMT054_V2_TO_FEB
  • Enter the following details and Click on view HTML.

 

The HTML output will show how the data is transformed and mapped to SAP back end tables.

There are mainly 4 tables that holds EBS information – FEBKO, FEBEP, FEBRE & FEBCL

 

How EBS is processed in SAP?

1. Run the transaction FF_5. Output Control parameters are important. Do remember to check all of them.

2. After importing the bank data from the XML, the program first transforms the bank data into SAP format (XSLT transformation)

3. Based on the Bank account in the file, program finds out the transaction types, in our case it is 19CMT054

4. Program then interprets the bank data based on External Transaction types in the bank statement and interpretation algorithm set up in the configuration.

  • External Transaction Types:

External transaction types are used in bank statement to notify what kind of transaction it is. It is a common identifier between the bank and the target system. In SAP, we will have to configure all possible external transaction types for the bank statement format, in our case it is CAMT 054. Some example transaction types are <54>353 used for withdrawal, <54>664 used for deposits.

  • Interpretation Algorithm:

Interpretation algorithm defines how the note to payee information from the bank statement will be interpreted. Refer to the below link for more details.

https://help.sap.com/saphelp_46c/helpdata/en/43/0bd56743de11d1896f0000e8322d00/content.htm?no_cache=true

You can use standard interpretation algorithm or create your own. Refer to the SAP note: 2032814 for the instruction on how to create Z interpretation algorithm.

5. Based on the Posting rules (Z022 & Z023) defined for each bank transaction type the bank items are matched with the company data.

  • Posting rules:

Posting rules will decide what to do with the incoming EBS transaction. Posting rules are assigned with the External transaction types. Choose + or – depending on whether the transaction increases (+) (deposit) or decreases (-) (withdrawal) the bank account balance.

6. There are 2 posting areas that we can post to while EBS processing in SAP.

  • Posting Area 1 – Posting in Bank Accounting
  • Posting Area 2 – Posting in Subledger Accounting

In our example, we have used only posting area 1. That means only 1 accounting posting will happen in Bank Accounting for each external transaction type. Refer to accounting entry 3 & 6 below. Please note that SWISHMAIN & SWISHCLEARING are just account symbols. The GLs have already been assigned with the account symbols.

If we choose Posting Area 2, another account posting will happen, that will clear the sub ledger directly. Refer to entry 2 & 5 below. This configuration will look like below. Posting type must be chosen correctly. The following posting types are available and needs to be assigned with the Posting rules.

Posting type 8 – Clear cred.subl.acct has been used for sub ledger clearing.

If both Posting Area 1 and 2 is chosen, 2 postings will happen for each external transaction type. First one will clear the Bank Accounting and the second one will clear the sub ledger.

  • EBS posting accounting entries:

Accounts Payable –

1. Vendor Invoice

Dr           GR/IR Account

Cr            Vendor Recon Account

2. Payment to Vendor

Dr           Vendor Recon Account

Cr            Bank Outgoing Clearing Account

3. Post EBS in SAP

Dr           Bank Outgoing Clearing Account

Cr            Bank Main Account

 

Accounts Receivables –

4. Customer Invoice

Dr           Customer Reconciliation Account

Cr            Revenue Account

5. Incoming Payment from Customer

Dr           Bank Incoming Clearing Account

Cr            Customer Reconciliation Account

6. Post EBS

Dr           Main Bank Account

Cr            Bank Incoming Clearing Account

 

  • After Posting the report will be shown as below. As per the import file, 2 bank statements are posted.

Journal Entries & Bank Statements 

External Transaction type can be seen in the BTC – Business Transaction Code column. Here BTC is <54>. Payment notes can be interpreted by Interpretation Algorithm.

 

  • Bank Statements can be reprinted using FF_6.

 

 

Understanding the EBS Back end tables:

Now let us understand the bank end tables in EBS. To understand EBS and how it works, it is important to understand how EBS is processed in SAP back end tables. We will see the table contents based on the above processed statements.

FEBKO – Electronic Bank Statement Header Records

KUKEY is the statement ID found on the top right of the bank statements

FEBEP – Electronic Bank Statement Line Items

External Transaction Keys are stored in VGEXT field. In our case, VGEXT = <54>-353 & <54>-664

FEBCL – Clearing data for an electronic bank statement line item

FEBCL holds the clearing information related to the processed EBS. In our case, we are using Assignment number (ZUONR) for clearing. The field SELVON is populated from the Payment Notes column in the bank statement. This table information can be customized using Z interpretation algorithm.

FEBRE – Reference record for electronic bank statement line item

Data in the VWEZW field will match with the Payment Notes information in the Bank Statement.

 

How to delete Bank statements from the buffer tables?

Run the report RFEBKA96 with Application as 0001 & bank statement IDs. In our case, it is 150 & 153.

 

 

Customizations in EBS upload:

How EBS processing can be automated?

  • SAP PI/PO or any middleware can get the CAMT 054 files from bank SFTP folder and upload in designated folder in AL11. The folder can be configured in SPRO.

  • 3 logical paths to be configured for the Inbound files, Processed and Errored files.

  • Above logical paths to be set up in the Define Import Parameter step

  • Run the transaction FEB_FILE_HANDLING with the source file path /INTERFACE/DEV/I0046/CAMT054/INBOUND
  • If the processing the successfully, the file is moved from Inbound folder to the Processed folder. If any error, the file is moved to Error folder.

 

I hope you enjoyed this blog. Please share your thoughts/corrections/suggestions in the comments below. Also you can reach out to me in the below link. Let’s learn together.

http://linkedin.com/in/theratulchakraborty

 

17 Comments
You must be Logged on to comment or reply to a post.
  • Hi Ratul, it's said that to have several G/L accounts for each Bank Account is recommened.

    "Several G/L accounts for each Bank Account" means, for example:

    • 6000101 is the G/L account for Main Bank Account, and
    • 6000102 is for Checks Received Clearing Account and
    • 6000103 is for Checks Issued Clearing Account.

    It's said that it's easier to process the manual bank reconciliation since the type of transactions are segregated, and if we're going to use ‘Automatic Bank Reconciliation [Electronic Bank Statement]’, Bank GL accounts with clearing are already in place.

    What's your opinion regarding this?

    Is it really much more difficult to manual reconcil the bank account if we have only ONE G/L account to each bank account?

    Is it impossible to have the bank account clearing if we have only ONE G/L account to each bank account?

     

    Thanks

    Song

    • Hi,

      If I take the example from the accounting entries 2 & 3 and 5 & 6 in my blog, you don't want to use 3 separate GLs. You want to use the Main Bank A/c GL everywhere.

      I don't think it is impossible to have the bank account clearing if we have only ONE G/L account to each bank account. But, how will you segregate the entries that were reconciled by incoming bank statement and the entries that were failed to reconcile? If you look at the journal entries, the main bank account G/L always has the balance of successfully reconciled entries. And the failed ones are kept as open in Incoming & Outgoing Bank G/Ls. This is definitely easier while manually reconciling the failed records.

      Cheers

      Ratul

  • Hi Ratul,

    Nice Blog and very well explained with the screen prints, this will very helpful for the SAP community, thanks for sharing.

    Keep up the good work.

     

    Regards,

    Eugene

  • Great write up, thanks for taking the time!  I'm having an issue that I wanted to see if you had encountered.

    We have some posting rules configured to clear AP documents based on the document number that is passed back in the payment notes (posting  type  4).  We have situations where we will have two statement line items for the same amount, each for a different outgoing payment.  However, when the posting program calls FB05 to post with clearing, we get an error for those line items that  the difference is too large for clearing, suggesting that the system did not actually use the document number in the payment notes to find the open item.  When I go through Search String Simulation, it finds the documents fine, but the actual FI posting still fails.  We can post-process in FEBAN just fine by entering the document number when we process open items.

    So it appears that when you use Posting Type 4 in your posting rule, and the program calls FB05, it only looks for line items for that amount does not search using document number.  Have you seen this, and do you have any suggestions to work around this?  Not sure if this is relevant, but we have only noticed this with KRW and JPY currencies, which are both zero decimal.

    Thanks,

    Wes

    • Hi Wes,

      Is it failing for all items or only for the statement item with same amount? If it is failing for all, then why don't you use your own custom interpretation alogorithm?

      Cheers

      Ratul

      • Hi Ratul,

        All the other line items post and clear properly.  In the latest example, the statement had 96 line items:  3 posted as expected using FB01, 89 posted as expected with FB05, and 4 failed with FB05.  These four were two pairs of line items for the same amount.

        We've used the standard 020 algorithm for years but only have this issue with line items with matching amounts.

        Wes

        • Hi Wes,

          If I'm not wrong, the algorithm 020 call the FM: FIEB_028_ALGORITHM in the back end. Please have someone debug it. I do not see any other option to be honest.

          Good Luck!!!