2 Replies Latest reply on Apr 17, 2009 11:07 AM by Hariharan Subrahmanyan

    How to do reverse accounting (or journal entry?) on a bounced check in SAP?

    Amanda Coggin

      Hi there-

      I am new to our company, new to accounting, and new to SAP. A steep learning curve I have in store for me.

      One of customers had their check bounce with us. Now we have a replacement check to deposit.

      How do we reverse that original check in SAP? Standard accounting practice, I understand, would be to do a journal entry on that original check. Our SAP consultants fix, they told me, was to go back to the day I deposited that first check, cancel the whole deposit, and then do new Incoming Payments for each check that was deposited that day (and include this replacement check). That seems like a lot of extra work with room for error.


      Please let me know what you have done in SAP when this has happened in your business.


      Thank you-



        • 1. Re: How to do reverse accounting (or journal entry?) on a bounced check in SAP?
          Andee DiCola


          What we do is create and outgoing payment to a GL account called "BAD CHECKS" using Bank Transfer payment means since the bank drafts the check out of your account. .


          Think about the bad check is a bank generated payment that comes out of your checking account separate  from the initial deposit.

          You need to leave the initial deposit alone as it will be on your statement to reconcile in full - not less the bad check.


          Then you will see the draft for the bad check. If you replace the bad check with another check to deposit, you would do an incoming payment to the same GL account "BAD CHECKS" that would be deposited again.


          If this was a customer account , then you could use a outgoing payment to the customer instead of the "BAD CHECK" GL account.

          Just depends how you want to track it.

          • 2. Re: How to do reverse accounting (or journal entry?) on a bounced check in SAP?
            Hariharan Subrahmanyan

            I agree in general with what the previous poster had suggested. There could be some slight differences in approach  depending on your company's policies on handling "replacement checks"



            Below sequence is based on the following assumptions


            a. your company uses SAP lockbox process -

            b. You send in the replacement check again to the lockbox and NOT to your cash concentration/main bank account and it comes back into SAP via the lockbox process


            If the above are true then the sequence will be as follows.



            I would identify that  particular check – FI document number- that cleared invoices, go to FBRA – Reset  Clearing document – I would reverse/reset that check in the CURRENT MONTH – I  cannot go back because my books would be closed


            This would be the resulting  entry


            Dr.  Customer

            Cr. Lockbox Clearing  account - ENTRY # 1  -  to UNDO earlier clearing


            Underlying invoices would be  automatically “uncleared” and become "open" again


            Then when you deposit the  check in the lockbox it would come in potentially without detail and then would sit  there as “on account” on the customer based on the match of MICR  number


            ENTRY# 2-  Lockbox posting


            Dr. Cash Clearing account

            Cr. Lockbox clearing account -   FOR what you sent back through the lockbox (not sure if this is the case in your company)


            The on account posting would  then post the following entry


            Dr. Lockbox Clearing  account  - ENTRY# 3

            Cr. Customer



            You can then go to FB05 or  F-28  FB05 – Customer clearing items you would then “apply” this this payment  against “re-opened invoices” and that would result in the line items being  cleared


            I would request you to  “mimic” this example in your test system especially if you are going across  month/ across year (if bounced check was an old check) to make sure you are all  comfortable


            You may wonder what happens to the amount that the bank would have debited for the bounced check. It would have to be initially booked as follows


            Dr. Bad Checks (GL Account) (represents collectively bad checks across customers)

            Cr. Main Bank account -  again my assumption that they hit your concentration account for the bounced checks


            This may not be mapped as such in your bank statement configuration if you do use that and may need to post this journal manually


            when you sent the replacement check through the lockbox, it would automatically hit your main bank account through the Lockbox sweep process thus washing what the bank debited when the check bounced initially


            So Entry # 1 would still remain open on the Lockbox Clearing account


            You would then wash this with the following entry


            Dr. Lockbox Clearing -  to offset what was posted in Entry#1 above

            Cr. Bad Checks account


            I agree this appears to be too many steps but you will notice that only 2 of these - the bad checks and the offset with the reversed original payment will need to be entered manually


            You may wonder why should I go through all this pain. It may be probably easier to just do the "bad checks" approach and leave the cleared invoices alone.


            But that would represent as if those invoices were paid with the "bad check" instead of the replacement check. They would be tied to an incorrect clearing document.


            Instead of going through this convoluted process you may probably go to the header of the "Original clearing document"  (check posting) and mark it with some kind of description in ref doc or header text to say, since paid with replacement check# xxxx or something like that.



            I see no reason why you  should do incoming payment for every check for that day?




            In my mind, it really depends on how strict your company's policies are in terms of document flow within SAP