SEPA is the new payment standard in Europe and wil become Mandatory in 2014. Are you ready ?

I was a bit surprised when I found this Blog entry, mentioning : SEPA is coming... I was surprised by the fact that the author mentions that this is becoming a FUTURE payment method. Actually, I worked for a Client where we started working on replacing classic payment methods with SEPA, two years ago.  It is true that SEPA will become a mandatory payment between EU countries, but only starting now may proof to be a big risk.

If you are a European company which is only looking into this solution at this time, you probably missed the boat. There is a considerable effort needed to setting up SEPA :
- Every business partner in Europe, must communicate his IBAN number. This includes every Customer, every Vendor ,every Employee and every Company Code in your organization will need to include information on BIC ( this was previously called Swift Code in SAP)
and IBAN before you can even start using SEPA payment methods.

- All your European Banks ( and countries outside the EU) need to be updated. IBAN numbers are country specific, so you need to find the correct source of information. Although the IBAN follows certain validation rules, the only proper source for the IBAN will be the originating Bank.  You probably will also need to update your bank data in a phased per country approach. The data is volatile, and changes over time.

- Processing Electronic Bank statements in SAP too is changing. Especially processing bulk SEPA payments may be a challenge to clear your statements correctly. The new standard ISO 20022 will provide for handling of SEPA statements correctly.
You may also need to to review your chart of account and implement new accounts to facilitate the new way of handling SEPA statements. Countries like France previously followed the ETEBAC format, but recent changes have made it necessary for changing this.


- Don't rely on SAP's Built in functionality to generate an IBAN from your existing data. Even SAP themselves do not recommend it. It would also be good practice to validate all the updated information with a third party provider. I have had good experience with Accuity. We followed the following procedure :

a) Download all bank data in an annonimous way and submit to the provider for analysis in SEPA enrichment. This will give you a good indication if the IBAN information you already have in your system is Valid or not.

b) Apply the 80 - 20 rule for all countries, Clean up your data. Your cost for conversion will be based on individual conversions of 1 particular business partner.  look what Customers/ Vendors represent 80 percent of your business. Look at historic data. You do not want to convert a customer's or Vendor's  bank account if he has not done business with you in the last 2 years.

c) Once you have your data prepared, you can submit it for conversion

d) When you get your newly converted data back, you can not just simply decide to update your business partners payment info without proper re-validation. You will need to build in a procedure or technique to validate your business partner's information. Dual entry validation can help in Centralizing this validation.

e) Executing your first batches of payments can cause some disruption in your electronic bank Statement Processing. Most Banks still have their own proprietary Bank statement, and even within a Bank, each Country may use different details in their Statements. Some Countries, Like Germany had specific reporting requirements. Although most of these requirements may dissappear over time, they still require attention from a legal reporting point of View.

f) Make sure you also consider that using SEPA mandates, may change the RISK involved with payments, particularly when Direct Debits are involved. In some Countries (such as Italy where they still use a 16th century Promise To Pay (RiBa) method which guarantees the Drawer of the payment to get his money. Some Payment methods restrictions in Italy will remain in place even after January 2014. Most traditional payment methods restrictions in Italy are waived until 2016.
You may find that the SEPA payment method may create additional risk factors which could impact your DSO or even Cash Flow. SEPA also means Slight changes in Valuation dates, as SEPA will be a faster payment and Valuation and Posting data for Bank statements will slightly vary.


Processing SEPA may well become a de-facto payment standard across Europe, but unless the USA starts adopting the IBAN standard ( USA currently does not have IBAN numbers for its domestic bank accounts), and International Companies must choose a EU member state as their home bank for EU business.
The same principle is true for Processing Bank Statements. As Long as US banks still use BAI or BAI2 format, Processing Bank statements for large International Companies with both US and EU presence, will still require separate Configurations and procedures.

FSCM becoming hot topic with existing SAP customers

SAP Financial Supply Chain Management Becomes more and more a necessity for existing customers.

With FSCM, SAP enables the ability to extend the Core SAP FICO functionality to area's related to it, which improve overall performance of FICO functions.

The Credit and Collections Management allow Easy Escalation for an AR department, while the Dispute Management Module allows you to Communicate with your Customers about outstanding Disputes.
The Client can interact through the Biller Direct Portal, so that Applying cash with disputed items becomes less cumbersome.
Cash and Liquidity , together with Treasury and Risk Management will allow your company to enhance Cash  flow Performance.


If you have about 6years or more in SAP FICO and at least 4 years with FSCM,  you can apply with IBM here.

Why IBM works

IBM offers equal opportunities. find Jbs at IBM .

 

In 1953, IBM President Thomas J. Watson Jr. issues Policy Letter No. 4, which states that IBM will hire people based on their ability, regardless of race, color or creed, one year before the 1954 Supreme Court decision Brown v. the Board of Education and 11 years before the Civil Rights Act of 1964. This letter is the first U.S. corporate mandate on equal employment opportunity.

IBM is hiring SAP FICO experts

IBM is hiring experienced SAP FICO experts in its organisations.
to view SAP FICO opportunities, Click IBM SAP FICO opportunities. Please note that you must have a current work authorization for the country for which you decide to apply.

Hear what working as a SAP consultant at IBM  (Please note that the youtube video is outdated. do not follow the link in the video)

You can also apply for other Positions, such as IBM SAP SD opportunities.
 

Speeding Time to Value for Retail Solutions with SAP and IBM

Check out how SAP and IBM help retailers Build Newer Architectures and Integrate Better processes. In the process, they speed up the Time to Value for Retail Solutions.

In the following Case Studies you can find examples of how Customers spot Consumer Trends or reduce storage requirements , or improve control and visibility of Stock Levels.

Are SAP FICO consultants in higher demand than others ?

SAP FICO Experts Linkedin Group

 A strange phenomenon seems to occur with my Linked-in Groups.  SAP FICO Experts 

Received more than 5000 Requests to join since its inception. 1500 of these requests were request from Recruiters to Join. Since this was not the purpose of the moderated group, Recruiters are not included in the FICO Experts group.

The purpose of the group is to share and communicate on SAP FICO topics and issues.

Members of the group are free to announce their own availability.

The ratio of actual Experts vs Recruiters for FICO (  is considerably higher than the groups for SAP BI Experts , SAP SD Experts  or SAP MM Experts .  These are more in the range of 5-10%.

EBS statements with MT940 : Search strings

I spent a few hours fine tuning my clients EBS settings.
The best way to customize the Posting is to analyze real time EBS statements , and fine tune them with search strings. The problem with that, is that MT940 statements are posting with different transaction codes, for the same bank, but in a different country. You can create search strings for almost any data found in the note to payee field. For the company in Poland for example, they activated Business Area as a segment for document splitting in order to be able to generate financial statements per business areas, within a single company code. The business area's are used to report on different business area's per country. So in order to automatically recognize the correct business area, there were exchange rates mentioned. For example : Any time there was a CSZ exchange rate mentioned, I knew it belonged to a particular business area for CZ ,and whenever HUF exchange rate is mentions, I use another for HU country. This is a good way for statement items which can be defined. but for other area's where it is not clear from the note to payee field, the business area is a mandatory field for posting, so the statement posting rule just goes to a red traffic light and users can just complement the posting in FEBA. There are usually not many issues with outgoing payments that have cleared open vendor items. As long as they have been mapped to the correct sub-account such items are usually auto-cleared in FEBA.
A bigger challenge is posting entries for a Market fund account, especially when the interest earned is not separately defined. such entries get tagged with an automatic payment advice note. Within FEBA, you can then change the principal amount on the payment advice, take off the interest part, post the difference to the interest earning account and clear the principal against the originial investment placed.
There are some gray area's where information is missing, so you need to park the statement on a suspense account. for example, in some cases, a investment account needs to be posted to. but there are different transactions, whith different currencies, requiring different GL Accounts. In those cases, you sometimes have to let the user decide where the posting will go to.
You make a initial posting to sub-account (reflecting a green traffic light) and then let the user transfer post the suspense account item to the actual GL account.
 Configuring Electronic Bank statements on SCN

Keeping you Chart of Accounts in Sync across multiple systems..

Are you trying to keep your Chart of Accounts in Sync, accross the same company code in multiple systems ? Sap Provides a way to transport the Generic Chart of Accounts (table SKA1), but not the Company Code Specific Version (table SKB1). The following technique allows you to do Both.

• Use the transaction FS15 to export your chart of accounts to a file (on the application server)

• (Double click on the message. you can copy the file name and path to your clipboard. )

• Use transaction CG3Y to download the file to your own PC.

• Log in to the other system,

• Use transaction CG3Z to upload the file to the other system

• For each client, run FS16 to upload your chart of accounts.

(keep track of the file path on each server so you know where it will look for the file)

You can use transaction AL11 to list files on the app server.

Sharing Status Spreadsheets in Excel

Did you Ever needed to track what other people updated on your spreadsheets?

Just activate the "track changes" under tools. (Excel 2003) .

Then send your spreadsheet out to several people.

Once you get the response back. you can merge all copies into one as a grouped update.

Note: don't forget to activate "track changes" BEFORE you send out your original, since Merging is only available on Shared copies...

If anyone uses Office 2007, please leave a comment with the option where you can find this in Excel 2007.

Sap Resources on esnips

Has quite some interesting resources on SAP. esnips is a community that shares resources amongst its members.