Skip to Content

Changing Vendor reconciliation account for MM

The MM/FI interface has a very useful table with extreme powerful possibilities to change the FI-Document during creation.

I had in several projects the demand to have a flexible method obtaining the Recon.Account at invoice posting. The SAP-Standard picks only the account from Vendor master data but has no functionality to change this as you can do it with FI-Documents manually.

Let us have a look into Table TRWPR. The table contains a list of Function Blocks preparing and changing data of the new FI-Document.

The FB AC_DOCUMENT_CREATE uses this table to prepare the FI Document. This table provides an interface for any functionality you want to implement.

  1. Create a new FB with the same interface like FI_DOCUMENT_CHECK
  2. make a new entry (DOCUMENT / CHECK / FI) in Table TRWPR with a number beginning from 900 and put your new FB here (you might copy the FI_DOCUMENT_CHECK record and change the number to any number between 900 and 999.

Your FB will be called at creation of the FI-Document. Table T_ACCIT contails the FI-Document positions to be created.

Here you find a short example simulated with the debugger:

I start with transaction MIRO and had set a breakpoint before into LRWCLF01/Form Document_Create line 499.

Posting the document stops at the break-point now.

Here you see the first line of the FI-Document to be created. With your own FB now you can manipulate any field here and that’s the right place to change the reconciliation account.

Here I changed the SAKNR and HKONT field to the new reconciliation account 1332116000 manually with the debugger. In the final solution your program code will do that.

The resulting document has now the replaced account instead of the original account from master data.

Please be very carefully when you manipulate data. You can screw up your system very easy and it is your responsibility when you manipulate data here.

Best regards =;-) Bernhard

You must be Logged on to comment or reply to a post.
  • Thanks for the good blog.

    Even though i don’t suggest this method to create the postings, ( i rather prefer to change the same in the Vendor Master data ), create posting and restore the recon value in the vendor master data. This way, the changes in the Recon account can be tracked. With the Debugging and changing route, i feel, you cannot track the changes.

    But the blog is good in the sense, it makes the logic for the process flow in SAP for postings.

    One point for clarification.

    When you have created a new function module ( copying from the existing one FI_DOCUMENT_CHECK, how the system will point to the New Function module ?

    There should be some link between the programme ( MIRO ) to call the new user defined Function Module.

    Pl clarify. Thanks in advance.


  • @Sivaprasad
    Thanks for your comment.

    The method I suggested allows to select/change the reconciliation account during posting. Our Customers needed different accounts to separate different types of invoices. So the account can not be changed at master data. Our customers have vendors e.g. selling assets but also services and want to have different accounts for this cases.

    With the debugging session I wanted only to show the principle.

    Activation of your code:

    If you add a line to table TRWPR then your code is called immediately. The SAP-Standard program reads all entries and uses them. Lines in the range from 900-999 are reserved for Customers use.

    So this is somehow a user exit, you don’t need any changes in standard coding  —> but please be extreme careful at implementing new functionality.

    best regards

    • Thoughts about implementation:

        1. Dialog
           You might extend standard transactions with customer screens and implement logic for selection of the account. During posting you might use this information for posting.

        2. No Selection by user
           You might implement program logic to select a new account, e.g. based on document types or anything else you might think of.

      This Blog shows only the principle and how to use table TRWPR to run your implemented function. It is not a ready solution -> use it as “how to” guide line.

      Best regards
      =;-) Bernhard

  • Hi Bernhard,

    Nice share and I also have this kind of request to reference your document, just the screenshot can’t display in web. Would you mind to update the pictures again? 🙂



    • Hello Regina, I will try to find the pictures, this message is now 3 yeaers old and I don’t have the originals any more.

      best regards

  • We used this solution. (TRWPR and custom function with interface similar to Doc_check. It works fine but in clearing, the bookings in vendor’s side are inpropriate. System post without change reconciliation account. In clearing it watchs at field umsks – (SG class) and this field is empty. Unfortunately implicit enhancment is nessecery.