Reply: 4

Auto translated

ELKO - electronic bank statement - introduction useful?

Hello,
we are just starting to deal with the topic ELKO - electronic bank statement.
I have the question, when it is worthwhile to introduce the electronic bank statement posting in SAP.
Currently we post the bank statements via F-28 /F-53/F-29 or FB50 (depending on the circumstances).
We have about 60 bank postings per day and the colleague needs about 2.5 hours per day to post and clarify the issues.
Approx. 80% of the time is needed for special matters (purpose of use unclear, double payment, unauthorized cash discount deductions, etc.).
I would be interested to know how much time is actually saved? What are your experiences?
The add-on providers advertise 70%-90% time savings, but this value seems to me very far from the practice.
Is an add-on worthwhile at all?
Thanks in advance for your answers.

You must be logged in to post a reply.

Login now

4 Answers

  • MrBojangles
    MrBojangles
    Hello TT_SAP,
    considering your booking volume, a separate add-on (which would have to be licensed additionally) is probably not worthwhile. At least the introduction of ELKO (in the standard) could be worth considering - for the following reasons (without claiming completeness):
    1. you would have the account statements in the system, i.e. you could view any account statement online at any time without having to go to the filing cabinet (ok - is probably not a decisive advantage)
    2. the posting process in ELKO is such that (if it's payments that involve OP clearing or similar) two postings are created:
    Posting area 1: Bank accounting (i.e. debiting or crediting the bank account against a defined bank sub-account).
    Posting area 2: Bank sub-account to current account or vice versa.
    I.e. even if there are problems with "finding" and clearing the OP's due to insufficient intended purpose information, the bank account is at least already clean and the colleague can concentrate on treating the "difficult patients".
    3. in newer releases there is a relatively comfortable post-processing function for individual bank statement items, which (assuming some familiarization) certainly saves a certain amount of time compared to posting the bank statement completely manually.
    Continue to have fun with SAP...
    Cheers
    MrB.
    Blog
  • tarsia
    tarsia
    Hello TT_SAP,
    I can only agree with the argumentation of MrBojangles. In my opinion, the use of the electronic account statement is worthwhile in any case. Even if the automatic allocation rate does not increase (at first).
    At least if you use the new postprocessing dialog (FEB_BSPROC) from EhP6. This has become much more comfortable and powerful compared to previous FEBA/FEBAN. My recommendation would be to start with the SAP standard without a third party add-on. Later on you can always check the use of an add-on.
    In my opinion, a relatively "inexpensive" but very effective way to increase the allocation rate is to use one or more customer-specific interpretation algorithms. Please feel free to contact me if you have any questions.
    Best regards
    InDieDa
    (IT Consultant, Process/Project Manager)

    Last edited on 18.04.16 09:18

  • broink
    broink
    Hello,
    I also agree with the previous speakers.
    In our case, we were able to save an enormous amount of time by the simplest means - using the SAP standard even without the enhancements in EhP6, only standard interpretation algorithms, some search patterns.
    The implementation effort was also kept within limits, however, 80% of the payment notes actually arrive at our company with invoice number. Instead of inventing very complex search patterns or our own algorithms, we decided to process the remaining 20% manually. During the setup process, the departmental assignment of GVCs and posting rules took the most time.
    However, we were already using the Multicash software before setting up the ELKO, so it was very easy for us to use the AUSZUG and UMSATZ files directly. I don't know what the hassle would be if the data arrived in a different format.
    Testing and adjusting the customizing accordingly by adding more search patterns etc. was also quite time consuming.
    For the introduction in the German "pilot company code" we needed approx. 2-3 months, whereby I would like to emphasize again that we consciously accepted an 80% hit rate when going live - one can certainly "art" oneself further for higher hit rates, but then also spend quite a bit of time for it
    The subsequent set-up of two further company codes (Germany and Austria) was a matter of 1-2 days, since these statements were also available in Multicash.
    many greetings
    b
  • broink
    broink
    small addendum:
    additionally, colleagues here see it as an advantage that the extracts are stored in the system. So they don't all have to be printed and statements from the past can be found and viewed quite easily.