Skip to Content

Field level authorization for customer and vendor master in SAP.

Hi folks

This might be a known information for some of you but I am sure that this is gona be a new learning for most of SCN users. I got a requirement to put field level authorization restrictions in customer master data and in the first instance I thought this might not be possible in standard because although we have authorization matrix level 2 but these are for some specific fields like sale order type, sale area etc but not for each and every field.

When I searched in Google and SCN I found some links discussing authorization object F_KNA1_AEN and I gave it a try and it worked. I thought I should share it with SCN fellows so here it is.

Go to this following path.


Here create a field group with those fields you want to allow for changes. All other fields will be in display mode for user.


In my case I want to allow user to change only withholding tax information. All other fields will be in display mode for this user. I have added all fields which are available in Withholding tax tab to field group 02.


After this assign this field group in user master’s role.


After Assigning this object and value check in XD02 for customer. All other fields will be in display mode and only withholding tax fields are in change mode.

We can use this object for different fields and tabs for customer master data.

For vendor master data authorization object is F_LFA1_AEN and methodolgy is same. Menu path is also same till Account Payables and Account Receivables and for Vendors Select Vendor Master and so on.

In short we can use F_LFA1_AEN object for vendors and F_KNA1_AEN for customers. Helping note is 864058 and SAP help link is here.


You must be Logged on to comment or reply to a post.
    • Hello Moazza,

      Thanks for the information.I have a similar requirement where I need to add field level authorization for following fields(Accounts Payable)

      • Baseline Date(ZFBDT)
      • Payment Terms(ZTERM)
      • Cash Discount Day 1(ZBD1T)
      • Cash Discount Percentage 1 (ZBD1P)
      • Cash Discount Day 2 (ZBD2T)
      • Cash Discount Percentage 2 (ZBD2P)
      • Net Payment Terms Period (ZBD3T)
      • Cash Discount Amount in Document Currency (SKNTO)
      • Cash Discount Base(SKFBT)
      • Paymemt Method(ZLSCH)
      • Payment Block(ZLSPR)
      • Partner Bank(BVTYP)
      • House Bank (HBKID)
      • Account ID (HKTID)
      • Exchange Rate (KURSF)
      • Translation Date (WWERT)
      • Amount in local currency (DMBTR)
      • Index Currnect Amount(DMBE3)
      • WHT Tax Code (WT_WITHCD)
      • WHT base (WT_QSSHB)

      Please revert.



  • I am somewhat surprised to see this security related blog approved by SCN.

    The main reason is that it is just a regurgitation of the documentation on the object. That documentation stares you in the face if you ever build a role for any of the transactions or hit F1 in one of their fields which can modify master data.

    Close on it's heals is that use of field groups and authorization groups is classed as one of the dumbest things you can do in SAP. It creates a large increase in retentive complexity (not least of which on role design and number of them, which is anyway an art form) but most end users are aware that it is only checked in the screens of a selected few transactions and not in the APIs, mass processing, LDBs, the larger part of ALV type controls and batch-input.

    That SAP proposes the object for display type core transactions without values such as XD03 / XK03 is normally a clear indication that it is best to get it out of the way by putting a * into the field. For the parts where there are no checks at all (you normally notice them quite quickly) SAP only offers the solution to modify the system.

    So... why regurgitate basic information and have you ever actually used these authorization groups of customers and fields in an organization with more than a handful of customers and survived it? The motivation for this blog seems suspect to me...



    • Dear Julius von dem Bussche

      Thank you for showing your concern and giving your views. As I have mentioned in my first line that this might be a known thing for many users but still there are a lot of functional consultants who don't know this. You are a security consultant with tons of knowledge so this looks like a basic information for you. I have shared this in SD forum where I am sure this is not basic and many of us were not familiar with this.

      I have always shared document and blogs which I have used at my workplace. I am using both objects for customers and vendors.

      I received a requirement that withholding tax information is something which they want to give a specific user. He'll have access of XD02 but he shouldn't be able to change any other field except withholding tax. We are also suppose to show him all other fields. What would be the best possible control or solution for this requirement? Please share your views on this.


      • Hi MoazzaM,

        Does the optional use of groups for master data records and fields not belong to basic training in the SD module? That surprises me somewhat - hence I see this document as a regurgitation of standard documentation which anyone with basic training should already be aware of.

        As optional feature it protects fields which the attribute (group) is added to. Permitting access to one field (set) only means that you must have created an alternate field group and assigned that to all other fields in all other tabs of master data maintenance. Although that only has the unfortunate consequence of doubling the number of roles for master data maintenance, further attempts to have a naming convention within a 2 CHAR field to create different slices of access to different fields for a limited person or time very quickly creates a mess.

        I certainly question such requirements before considering a solution with a big impact (e.g. it might just be an apprentice who they want to have maintaining some master data fields for a few days - no need to turn the security relevant customizing on it's head for that..). Even so there is an alternate after-the-fact control if you use the check flag "Not authorization relevant" on the field -> you can then have a batch job running looking for changes to the fields outside of the group by user NE the user and IF FOUND then send an alert mail to the MD team. That is certainly more security friendly and if the business process changes you can easily change the variant for what is monitored and not have to turn customizing and master data around again.

        A blog on the pro's and con's of preventative vs. detective controls in master data maintenance would be interesting to read about what works for others. Repeating documentation is not interesting (at least it is not for me and I rather read the documentation of the current release I am on incase something changes - eg. the search helps were extended for authorization relevance recently but that is not in the 4.0 documentation...).



        • Hi Julius

          Thanks for explaining in this much detail πŸ™‚

          If I explain customer group fields KNVV-KONDA, KNVV-KVGR1 to KVGR5 here then those would be basic from SD point of view. I have been working as SD guy since 2009 and I got to know about this authorization control last week. This might not be the case with everyone else but may be for some knowledge seekers like me.

          I have shared SAP help document and sap note for more clarification and for references. In help document they have explained the use of object and I have added a real time business requirement and some screens with menu paths etc. I know this is not that much technical or advanced for you or other senior members but here in SCN we have users and members from different career level and unfortunately no document was there in SCN. I actually searched in SCN and google and couldnt find any document explaining this with screens and example so I posted this document here.

          The process you have explained is another alternative solution for this and that can be chosen by some very big clients where they have big teams for MD but in our case we have one user who maintains master data for customers in SAP. Finance guys were always with an excuse that sales guys are in a habit to put wrong information in withholding tax fields. So the requirement was to give this authorization permanently to FI guy and now whenever a customer master data is opened in SAP withholding tax data will be maintained by FI guy.

          I did some R&D and this was the best possible solution which I came up with and have implemented for customers and vendors both.

          I have shared some very technical documents as well but it is not always for experts and gurus like you. Sometime we have to take care of beginners and middle level users as well. I am including myself in middle level users because still I am not familiar with many of the things which I should know. Thank you for your concern again and I appreciate that you noticed it and shared your views.


          • When I was searching in Google I actually had seen this link. There are two things I want to tell you about this link. The discussion was not marked as answer as the issue was not exactly resolved. In this whole disccusion Ravi Sankar Venna is most senior user and see his reply. He said that in FI we don't have this kind of structural authorization.

            Well you could find another link which has more relevancy and Atif has explained it well. Just check this link.



          • Hi MoazzaM,

            Attn: Julius.

            Very Happy New Year to you both and to all of the readers of this post πŸ™‚ !

            MoazzaM, I share your passion of sharing knowledge so that people who have lesser experience than us get new inputs and expand their SAP Knowledge. This trait of yours is commendable and not many people do this now a days.

            I love reading your replies in these posts and you being a Top Contributor to the group is a nice example of the gift of sharing of that knowledge.

            While what you may read further might look like condescending statements from my side, the intention is purely to try to bridge the gap of understanding and interpretation of the concerns from different worlds. You have already done your part in this direction, but coming from a third person like me might help further help the case.   

            Also, I have some minimum exposure to working together with Basis / Security so that makes me a little comfortable in sharing my thoughts here.

            Here are my two cents:

            What Julius may be pointing out is that while it may look like there is a easy / direct solution to problems we face for field level authorizations in the Customer / Vendor Master specifically, this type of document is more in tune with a narrow interpretation of Authorization Groups usage and Authorizations in general.

            As pointed out, this might turn out more of a bigger impact item than what may appear to be a simple solution. Further, most of the times, the SD / FI Users are not even be privy to having authorizations for such activity. Most likely that is the case, everywhere. This has to be done by Security/Basis in conjunction with SD / FI Folks rather the other way round which this document may unintentionally convey.

            This post has reopened my eyes on the difficult walk of sharing knowledge yet not assuming that a solution is easy / robust / has low / no impact to other modules. I myself have been a culprit in such situations in the past so try to be very careful.

            When we give documentation on any topic we may want to limit ourselves as much as possible on what is normally considered as regular feature of our specific module.

            This document might give a wrong sense of security [pun unintended] to people who are new / less experienced in SAP as having specific solutions whereas this may lead to more head aches for Security/Basis to deal with.

            Personally for me, SAP being an integrated system, this kind of information[without going into the debate that this is redundant / regurgitation ] when shared does expand the existing cross module knowledge of SAP Consultants, but as said earlier [ to the point of repeating ] has the danger of imparting half baked wisdom for some Functional Folks. That I think is one of the concerns shared by Julius and I fully subscribe to that too.

            Julius : I do have to share my experience in this point. I have been around in SAP for sometime and I did undergo proper in depth SD Consulting Training but this is not something which was covered as a basic topic. May be in that sense my training was probably not so detailed after all πŸ™ .

            That being said, I do know of this feature and use based off my knowledge in the practical project environments and my generic knowledge of Auth. Roles and Profiles Creation using PFCG sitting with Basis[not security as it is segregated today

            MoazzaM: You may want to include some caveats on the potential bigger impacts on Authorizations  / Security related issues which would crop up on trying to implement this specific solution.

            I rest my rant πŸ™‚

            Apologies if some part of my statements may not be agreeable to anyone.

            Have a good day gentlemen.


          • Dear Dee Sea

            Thank you very much for showing your interest and sharing your views in this detail.

            As I mentioned earlier that this is just a way to control this and I have done this with my ?BASIS guy. Even though I know a little about roles and authorization objects etc but I have always taken concerned person in loop whenever I made any change in some other area other than SD. This was the best possible solution for us and its working fine. As far as this document is concerned I am in a view that this is just a knowledge sharing and I have tried to simplify it. If someone hit in Google with text field level restriction and he finds this document, he will obviously analyze it, discuss it with their BASIS guy and then decide whether to go for this option or not? This document is not mandatory to implement.

            In SAP sometimes we have many alternative ways to control one thing these ways can vary for every user depending on their business, culture or may be requirement's background etc.

            Thank you once again for showing your interest.


  • MoazzaM

    These sort of activities are purely lies with Security team.  Also since you yourself have indicated

    I have shared some very technical documents as well but it is not always for experts and gurus like you. Sometime we have to take care of beginners and middle level users as well.

    definitely, no beginners or middle level users should try this considering the fact that in a real time projects, they would not be handling this.

    Also, ideally, this blog is applicable to beginners or middle level users of Security and not functional consultants.  Hence, this can be moved to Security forum.

    G. Lakshmipathi

    • Sir

      Ideally this is security team's responsibility to control and manage this kind of authorizations and this is also SAP best practice. Being on functional side we should at least know this whether it is possible or not and if possible how we can do this. This is my personal opinion which you or other users can agree or disagree.

      Since it is regarding customer fields so I posted it here. If you think this should be posted in security forum then you can move it. If you and Julius think this document shouldn't be posted in any of forum you can remove or hide it. I am saying this with positive attitude and I don't want to go against community rules.


      • I certainly agree with you that application security goes hand-in-glove with application functionality and a functional consultant who participates in solutions is worth gold. For sure it should not be the responsibility of basis to make such decisions and a functional consultant who is closer to the application owner is the best option for bridging the gap between the system and it's use.

        In reality out here they however mostly just memorize SPRO paths and go to meetings... πŸ˜‰

        Cheers, Julius

        • Dear Julius

          You would be surprised to know that I am SD guy but I have worked on authorization roles, objects and fields a lot. We had to create new users and our BASIS guy asked us to create roles in DEV server and they just downloaded those roles and then uploaded in PRD. This is the reason we have to work with these security issues as well and I have tested this document on my own and then asked BASIS guy to just give authorization of this field group to user.

          Although this is not our duty but sometime we have to do it so its better for our learning and knowledge. I think having knowledge of multiple areas is not a bad thing.

          Thank you for agreeing with me. Thank God there is at least one person who agreed with my one point πŸ˜€


          • Sir

            As you can see a big smile at end of the message and it shows that I said this just for fun. There is nothing serious or negative attitude in my statment. I didn't mean that what you understood and this is drawback of written communication that you can't show your emotions even though I tried but I think I am failed in that. I am sorry if you took it in wrong sense but I said that just for fun.


  • Dear Suseelan Hari

    Please test this and update me if you feel any issue. I have shared SAP note relevant to this document. You can take help from that note too.


    • Hi MozzaM,

      I really appreciate your passion to share knowledge.

      Infect though this is technical information, its very useful for functional consultants considering, sometimes new Technical consultants does not know all these points and these questions comes to us for answering that is it possible in standard SAP or not.

      Thanks for sharing.

      Have you come across similar requirement on Sales order or Delivery or any other SD transaction creation where User is supposed to change only One field. And that is only if he has authorization for that specific field change?



      • Hi Mahendra,

        What you have seen is authorizations specific to the Objects Customer Master and Vendor Master. These are master data related transactions.

        Sales Order, Deliveries and Billing are Business Process related Transactions. These have different controls than Master Data.

        It may not be feasible so easily for these as there are different controls for them, but I leave it to MoazzaM to answer that.

        MoazzaM:  You may need to set the right reader expectations from this document with respect to limitations and caveats.


      • Hi Mahendra Jani

        Thank you for your words and yes I came across such requirement for sales documents. For that we can use custom authorization object. We have to create object in SU21 and then assign that in respective userexit with authority check logic.

        Dee Sear is right that these objects are for master data. For transactional data there are different controls. Sometimes we can can control through custom objects and sometimes through SHD0 variant.


        • Hi MoazzaM,

          I like your confidence in these things. Happy to note that this is doable. πŸ™‚

          Even though I have extensively worked with Basis/Security, personally, I would like to be on the safer side of things πŸ™ and think of having extremely limited knowledge on this topic.

          From what I was made aware of by Security Guys [worked with some big Industry Gurus on that] there are certain limitations on this topic with respect to Transaction Data.

          I believe Transaction Process Programs are more complex than Master Data and there are lots of different points in the program where these Authorization Specific Fields could be potentially get called on. Whereas the Authorization Checks basically take place only on certain initial screens and further checks do not take place or they are not effective.

          Anyways, what I am discussing here is a theoretical topic and every requirement for these kind of transaction can be different so will leave it at that.

          That being said, happy to know that you seem to have a grip on this subject, which is true Cross Module Knowledge[something rare between SD & Security].

          My sincere advice to you would be, to write a document with different scenarios [especially the Sales Order one] on this topic and may be publish for the benefit of SAP - SAPPHIRE audience. That will be a good exposure.

          I will log off from this discussion now. I don't think I will be a good contributor any longer for this topic.

          Have a good one.


          • Hi Dee Sea

            For security and authorizatin we have authorization objects and screen variants etc sometimes there are many ways to control one field and we have to see which option is suitable for it.

            For sale order process we have certain userexits where we can add customized authorization object for any field and can control it user wise.

            Thank you for your advice and I will see if I could do that.


          • Hi MoazzaM,

            I do understand many of those things[if not all] being in this field[pun unintended]  for a good enough amount of time.

            I may not know the exact object names, user exits, Auth. Profile names, Etc. for the particular mappings, but that is I believe in the larger scheme of things should be not so difficult. 

            I get the whole nine yards with respect to the concept, the touch points and that is enough for me. Thanks and Hats off to you for that.

            I had other points which I think at this stage are irrelevant and to repeat again, I dont think I am any longer a positive contributor in this post, so I will close my rant for the last time and for sure, stop following this post.

            You have a good day.


            PS: The above being said, you can still think of sharing this knowledge with SAP SAPPHIRE audience. I believe it is worth the effort. πŸ™‚

  • Dear Moazzam,

    Really helpful document.

    I have tried to do same with Vendor Master, the only issue I have faced with the process is that I'm not able to find out Fields related to vendor master.

    Every time it is saying that "field name 'xyz' is not allowed."

    Can you please provide me list of fields for the same which can be applicable to Vendor Master.

    I want to allow user to change only withholding tax information. All other fields will be in display mode for this user in T-code XK02.

    Please help me with this...


    Parth Raval

    • Hi

      I hope you would have found some solution. I am sorry I couldn't respond you timely. Let me know if you have still the same issue.


      • Dear Moazzam,

        I have done this through screen variant finally.

        Please let me know how we can do this in vendor master using field authorization. I want that list of fields.

        Thanks in advance.

        • Hi

          I can see all the fields available for vendor in below node. Please check again and follow the document steps for vendor. You should be able to do this as this is standard functionality.



          • Thanks MoazzaM for answering my queries.

            But as you have mentioned in your original post, I want field names for withholding tax tab for vendor master same as given by you for customer master.

            Please find below snap from your post.

            " In my case I want to allow user to change only withholding tax information. All other fields will be in display mode for this user. I have added all fields which are available in Withholding tax tab to field group 02.


            Thanks and Regards,

            Parth Raval

          • /
          • Thanks a lot Moazzam. I will try the same using these fields and get back to you if face any other issue.

            Can you please also share the path where do you find these fields..??

  • Hi MoazzaM,

    thx for this really useful manual, I had to create a new role for a customer which in XD02 would not be able to edit Payment Transaction fields but all the others, so creating a field group with that bank data and assign that field group to the authΒ object works! πŸ™‚

    The thing is, I need to do the opposite, I mean, grant access only to Payment Transactions fields but not to the rest of the XD02... I could create another field group and add ALL these fields .. but could be really hard .... Is there any other way to do this? to have the whole XD02 not editable but only some few fields from Payment Transaction tabs by a role?


    • Hi


      Sometimes in life we need to take hard decisions and I believe this is one of those for you πŸ™‚


      I don't see any other way without using ABAP or screen variants. In standard this is the only way I know dear.