SAP Expert has a very popular article already about the Bank Statement Process in SAP. That article is based on the “old” SAP transaction for post-processing of bank statements: FEBAN. In fact, FEBAN was already the second generation of such transaction, first of which was the single-screen FEBA. The difference between FEBA and FEBAN is like a difference between FB01 and FB50. Both FEBA and FEBAN had their advocates.

Let’s not go deep into that conversation. SAP introduced a new, third generation of bank statement post-processing transaction few years ago. They did not change the transaction code. It is still FEBAN. But this is a New FEBAN.

Let’s have a look at what is actually new in New FEBAN.

Design

The most obvious change is the design. Instead of tree-structure bank statement layout on the left and line item details on the right, new FEBAN has three horizontal sections.

The top section lists line items selected through the selection criteria, so-called “Worklist”.

The middle section gives you an overview of an individual transaction, its amount, text description and so on.

The bottom section allows you to run cash allocation activities, attach documents and check the logs of the line item processing.

The table sections in the top and bottom part of the transactions are configurable through the standard ALV functionality. Moreover, the bottom part tables can be used for data entry in the corresponding fields.

Cash allocation options

New FEBAN allows you to be flexible in the way how you run the cash allocation for the transaction. It no longer limits you to the use of FB01 or FB05 which are called by the “Save” button. Instead, you can search for invoices to clear, allocate amounts in full or partially, post amounts on customer, vendor or even GL account. All that in any combination and without leaving the single screen, just switching between the tabs. The only limit there is that you can post the document only when the balance is zero. Quite logical it is, isn’t it?

Transaction details editing

Yes, you read this right. You can edit, enhance, amend the transaction details right from the New FEBAN transaction. Of course, you are limited to what you can edit. You cannot edit amount, sign or external transaction code. But you can change the internal posting rule, add some batch-input field information (like in the search strings configuration). And what is the most useful, you can change the Remittance section of the bank statement line item.

Why is it the most useful? Because all your interpretation algorithms and search strings use the Remittance (Note to Payee) section for their work. And nowadays you may have remittance information not only through the bank statement, but also from email, online platform, phone conversation and so on. For example, you can copy-paste invoice numbers related to the customer payment from an email received from that customer financial department, and then “Scan” the Note to Payee section again, asking SAP to automatically find the invoices related to that payment. It will not only run search algorithms for finding the invoice, but also use search strings that may redefine the posting rules, populate extra fields and so on.

That is truly convenient, believe me.

Posting simulation

You have an option to simulate the financial document without actual posting, like you do it in normal FB01, FB05, FB50 and so on transactions. That is just another useful option to validate the document before it hits the accounting books.

Document reversal

Once the document was posted in “old” FEBAN, you had no option to re-process the bank statement item. Of course, you could reverse the document itself and post a new document again. But that new posting would have no link whatsoever to the bank statement. FEBAN would still list an old document against the line item.

Now you have an option to reverse (and reset clearing if necessary) the FI document right from the FEBAN screen. Once reversed, you can reprocess the bank statement line item again using all the same functionality as in original posting.

All the postings and reversals are kept in the FEBAN log, so you can have an audit trail.

Manual change of status

You can now manually change to status of the bank statement line item between Open and Completed. Yes, that is without actual posting.

Relationships browser

The posted document number is shown against the bank statement line item in FEBAN. That existed even in the first re-incarnation of the bank statement post-processing transaction FEBA. But now you have a reverse search functionality. Right from the posted document you launch the Document Relationships Browser, and get back to the statement line item overview.

Well, that is not directly linked to the New FEBAN transaction, but still a worthwhile addition to SAP functionality.

Conclusion

As you can see, SAP worked hard on improvement of the bank statement processing transaction and its usability. It now became really useful and user-friendly

Have you tried that new FEBAN transaction yet? Maybe you can add some more features that SAP Expert forgot to mention here?

Do you have questions about using FEBAN? Why not ask a question to SAP Expert?

When we say “Bank statement”, we most often mean the statement that bank provides to us (person or company) with a list of transactions from the past. These are the transactions that already happened on account. They affect available balance on account. They cannot be changed or back-dated.

When talking about bank statement formats, these are SWIFT MT940, BAI2 and many other country- or bank-specific formats, and even FINSTA IDOCs. SAP provides multiple options to upload these bank statement formats.

But these end-of-day statements are not the only ones that banks may provide, and they do provide. There are also intra-day statements.

These intra-day statements contain the information about transactions happening on the account during the day. They are not necessarily confirmed, as there is a chance that some issues may cause the cancellations or delays. But there’s still a chance that these transactions will make their way to the end-of-day statement, which we will receive tomorrow. There can be multiple intra-day statements covering transactions at different time intervals.

Why are they needed? Mostly for cash position reporting. If your company trade volumes are measured in millions, every single transaction may affect your cash position both in negative and positive direction. Treasury needs to plan cash position and act quickly to avoid unnecessary overdrafts and bank charges.

Another use of intra-day statement is to give the credit control team idea about customer payments. Why would you need to chase the customer payment, if your bank already informs you about the transfer to your account?

What are the formats available for intra-day statements? Just to name the most common: SWIFT MT942 plus the same BAI2, and also FINSTA IDOCs. Of course, BAI2 and FINSTA have special indicators to distinguish end-of-day and intra-day files. SWIFT MT940 and MT942 are very similar, but even they have their unique tags, which only appear in one format, but not in other.

What can you do with intra-day statements in SAP? Of course, you can import the intra-day statement files into SAP. But SAP understands that these transactions can yet be cancelled, and it does not make any postings based on intra-day information. Instead, standard SAP program can create Cash Management Memo Records (Payment advices). These memo records can then be viewed in Treasury reports.

The pre-requisite for Memo Records (Payment advices) creation are checkboxes “CM Payment advice” and “Account balance” on the selection screen of MT942 import. Another important thing to remember is that SAP only accepts SWIFT MT942 statements in “Field 86-structured” format. Is your file coming non-structured? There’s a workaround. SAP Expert will be happy to advise if you ask.

Are you using intra-day statements in your company?

Hello, dear friends. First of all, let me introduce myself. I’m Vitalii and last 15 years have been working in SAP HR/HCM field in global companies with 50k+ employees. I’m a top SAP HR blogger in Russia at https://saphr.ru and have recently started my English version of blog at https://saphcmsolutions.com

Today I want to share with you how to generate SAP Business Partners from Employee records. Finally we’ll have personnel number in SAP HR in PA20 transaction and a business partner with Employee role in BP transaction. SAP Business Partners are core entity in S/4 HANA solution as it allows to look at the same person or company under different angles. The same person could be our employee and vendor providing office supplies in his spare time. If we work with staffing agencies we can have one business partner as an agency with multiple contractors working through this business partner. And all of them will be linked together with relations in SAP Business Partners functionality. Good thing – it’s free of licensing. Setup and use it.

I assume we have a clean green-field installation (a development client was copied right from 000), so many default things could be skipped.

By default we have all switches set in ‘Activation Switch for Functions’. Also default Employee role is predefined by SAP with code BUP003 (see V_TB003).

Under ‘Number Ranges and Groupings’ it’s important to setup correct number ranges. I prefer to use internal number ranges.

Here we can setup HR Employees and Org units integration with SAP BPs. Go to ‘Activate Integration’ and make switches look like this.

For testing purpose let’s activate logging functionality in ‘Activate Logging/Error Analysis for Data Synchronization’. I’ve set HRALX MSGRE switch to 2, so all processing errors will be sent to my SAP Office mailbox in SBWP transaction.

Let’s synchronize our current employees with BPs. Open SE38 and run program HRALXSYNC. Tick ‘Employees’ on the first screen.

All red icons show us the data differences. Click the right-most button in the toolbar to sync the data. After it finished open transaction BP and search for the new business partners. Here what I have.

SAP synchronizes several infotypes by default, like personal data (0002), address (0006), org assignment (0001). If we want to provide some more info or change the behavior, then BADis could help.

If we reran the same program and choose ‘Organizational Units’ on the first screen it would have created org units as business partners and relations between org units and employees.

Tax code in SAP is an object that determines the tax treatment of certain transaction. It also drives the postings generated be the system when the tax code is used.

Generally speaking, there are two types of taxes that are relevant to SAP Finance postings: withholding tax and sales tax. This article is about sales tax codes. To limit out scope even further, let’s concentrate on sales tax how it works in Europe and some other countries like Singapore, Australia etc. The ideas may also be applicable to other countries, but be aware of local requirements that may not be fully covered here. Some other countries like USA and Canada use their own logic for sales taxes. They are not covered here at all. This article will also use term VAT, which is sometimes interchangeable with term GST in certain countries.

We have already covered special cases of tax postings. Today we will talk about more standard business processes.

There are some different types of tax codes in SAP system. Each of them serves its own purposes and has its own setup. Let’s check these types in details.

Regular purchases or sales

This is the most common type of tax code. It usually applies to domestic purchases (or sales) from a VAT-registered company. Tax rate depends on the country and type of product. It is specified in tax condition with account key VST for purchases or MWS for sales.

When the document is posted with such tax code, the VAT amount is posted on a separate GL account waiting for further processing during the tax return process.

Purchase and sales without tax

There are some scenarios where tax is not applicable to the transaction. This can be 0%-rated domestic transaction, or transaction not relevant to tax at all, or transaction with a foreign entity. Generally speaking, all these transaction contain 0% tax rate in VST or MWS account keys. Technically you can do with only one tax code for sales and one for purchases, but it is usually recommended to create several of them, as per requirements of tax reporting.

Of course, no separate line item for tax is generated in FI document from such tax code.

Non-deductible purchases

There are certain cases where purchase of a product or service is done for company’s own needs and VAT on such purchases cannot be fully or partially claimed in the tax return. In this case, tax code should be created with tax rate in condition with account key NVV.

This condition determines necessary amount of tax and distributes it across the GL accounts for costs or products purchased. It may be stock, P&L or GR/IR account depending on the situation.

Intra-EU purchases

European Union (EU) is a political organization that includes several states. The Union has its own policy on inter-EU trade, goods movement, accounting and so on. One of the rules applicable within EU is that sales between companies registered in different EU states usually bear zero VAT. While sales part of that transaction is covered in the section above, the purchases part has its own complexity. It is called “reverse charge of VAT”.

In short, buying company needs to reflect the VAT amount with domestic rate as both sales and purchase transaction. They offset each other, making zero in total, but still need to be shown in GL accounts and in tax reporting. That is why tax codes for such transactions use account keys ESE and ESA with domestic tax rate associated with them. Two additional line items appear in the finance document with such tax code.

Full-revenue sales

Majority of states require posting of customer invoices showing only net amount as revenue, while the tax part of the invoice is posted to VAT account. For a 20%-rated tax code the posting looks like:

However, some countries (e.g. Russia) require different logic for sales-related taxes. Gross amount of sales should be posted to a Revenue account, while special GL account “VAT on sales” is posted with VAT amount only. In theory, the posting should look like this:

While it is not technically possible to post Cr Revenue 120 in this case, the following logic is used in SAP:

It means that, in addition to standard logic of sales transaction, two more line items should be created from tax code treatment:

That is why tax code conditions with account keys ZUD and ZUK are employed to generate these line items in FI document. It means that tax code contains three active account keys: MWS, ZUD and ZUK.

You can understand that one of the GL accounts assigned to tax code posting is actually a revenue P&L account. If you have several P&L accounts for revenue postings in your Chart of Accounts, then you need to create as many tax codes in your system, and teach your users to use a correct tax code in each transaction, or use a correct tax code determination for automatic postings.

When you created necessary tax codes in your development system, please remember that there is a special procedure to transport them across the landscape.

What types of tax codes are used in your SAP system?

SAP Expert published multiple articles about the bank statement process in SAP. We looked at the ways to import the statement, the ways to process the end-of-day and intra-day statements.

Now let’s have a look at some interesting aspects of configuration behind the Electronic Bank Statement process.

You are probably already aware of the four main steps in Electronic Bank Statement configuration:

1. Create and assign Account keys
2. Create and assign Posting rules
3. Create Transaction type and assign posting rules to them
4. Assign bank accounts to Transaction type

You can already read a lot about EBS configuration in the free e-book by SAP Expert.

If your bank statement transactions can be easily classified by external transaction codes only, then all works in a pretty standard way . But what if you need to do something extra? Like find profit centre based on POS terminal code quoted in the text? Or change posting rule based on text description of the transaction?

Here we come to search strings for Electronic Bank Statement in SAP. What are they?

Search strings is a functionality that looks at the description of the bank statement transactions, like tag :86: in SWIFT MT940 format, and searches for the symbol sequences (read: pieces of text) that you configured. Based on the finding, it can do a lot.

So, how does it work?

Search string definition

First of all, you need to define the search string itself in transaction OTPM. It can be a fixed text like “BANK CHARGES” or a more complicated set of characters with wildcards and additional logic. Press F1 on the search string field and you will get a nice help page with plenty of examples.

When you define a search string, you can put the mapping directly there. For example, you can map combination “123123123” (as quoted bank account number) to “999888” (as your vendor number), so that you can directly use this vendor number later. Alternatively, you can leave mapping fields blank. It means that search string will only be a trigger for further actions, which we will discuss in few moments. If you want to leave mapping fields blank, don’t forget to remove the search string auto-mapped characters from the right column of search string definition.

Once the search string is defined, you can put some text in the special window and test if the search string really works. For example, you can copy-paste the text from tag :86: of your MT940 file.

Search string use

The second step is activation of search string, “Search string use”. Here you specify under which conditions your search string should be attempted: Company Code, House Bank, Account ID, External Transaction Code, Interpretation algorithm and so on. As for Interpretation Algorithm, it should either match the one from posting rule assigned to external transaction code, or you can put “999” for any algorithm. Most of the fields in the list above can be left blank, so you don’t need to make multiple records for each combination of Company Code, House Bank, Account ID, if your search string is really universal.

Then you specify the search string to be attempted by the EBS processing program. If your defined search string is found in the text, the rest of the table starts to work. First of all, you define which fields you want to populate or replace when the text is found in description of bank statement line item. These can be Posting rule, Cost Centre, Profit Centre, GL account, [Business] Partner and it’s type (vendor or customer) and some more. You also have an option to populate 3 fields in the posting not directly listed in the drop-down list. This gives you a lot of flexibility indeed, only limited by number 3. If you want to use these fields, you first need to define their names and then their values. You can also optionally restrict the use of the search string by debit or credit side in posting area 1 or 2. If you do not restrict, then field will be populated on both sides in all active posting areas.

And last in the list, but on the top of the importance hierarchy stands the configuration field “Prefix”. This prefix is used to add characters to the values produced by search string mapping. For example, prefix 0000000000 (ten zeroes) with search string mapping 123456 will produce output 0000123456. But what if the search string value itself is empty like we discussed few lines above? Then Prefix becomes the only value passed into the posting. This means that you do not need to populate the mapping value in the search string definition. The search string will only work as a trigger. The Prefix values are what will be really passed into the posting. This way, you can use the same search string for different purposes. Just one example: the same search string can be used to define batch input field and batch input value. Just leave the mapping blank and put field name and value right in the Prefix column of Search String Use configuration.

Finally, tick the checkbox “Active” to activate the search string.

So, we defined search strings with their mappings, and configured their use. What is next?

Next is moving changes from configuration to test client and uploading the test statement file. Did it work? Congratulations!

If you have more questions about the search strings for Electronic Bank Statement in SAP, why not ask SAP Expert?