V_VBAK_AAT — Sales Document Type Authorization Check
V_VBAK_AAT controls which sales document types a user can create, change or display, checked against the ACTVT and AUART fields whenever a sales order transaction opens a document of a given type. A failed check almost always means the role has some order types authorised but not the specific AUART the user is trying to process.
V_VBAK_AAT is the authorization object that governs access to sales document types within order processing transactions such as VA01, VA02 and VA03. This page covers the fields it checks, where in the transaction flow the check fires, and how to isolate a failed check from the more commonly blamed sales area object.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 930 words
What it protects
V_VBAK_AAT guards access to sales orders at the level of the document type itself, independent of which sales area the order belongs to. The structural fact that causes most confusion: a sales order create or change action is normally protected by at least two separate authorization objects at once, one for the sales area (org level) and one for the document type (this one). Both must pass. A role can grant full access to a sales area and still block the user if the specific order type used on that document, standard order, rush order, credit memo request, whatever it is, was left out of the AUART value list. Consultants who only check the sales area object miss this every time, because the error message from a failed org-level check and a failed document-type check look identical to the end user.
Fields checked
- ACTVT - the activity being performed: 01 create, 02 change, 03 display are the ones that matter in day to day order processing; some roles also carry 06 delete or 08 display change documents.
- AUART - the sales document type itself, for example OR for standard order, CR for credit memo request, RE for returns. This is the field almost always at fault when the check fails, because it is maintained as an explicit list of values rather than a range, and new order types introduced later are easy to forget.
Where it is checked
- VA01 create sales order - checked immediately after the order type is entered on the initial screen, before the sales area fields are even processed.
- VA02 change sales order and VA03 display sales order - checked on document open, using the AUART already stored on the existing VBAK record, not whatever the user might type.
- VA05 and VA05N order lists - checked per line when the list tries to open a document type the user has not been authorised for; those rows are filtered silently rather than raising a hard error.
- Background and batch input processing for order creation, including IDoc-driven order creation (inbound sales order IDocs), which fails silently in the log rather than showing SU53 to anyone.
- Mass change and copy-control transactions that create a follow-on document of a different type than the source, where the check runs against the target AUART, not the source one.
How to trace a failed check
Start with SU53 run immediately after the failure, while the session is still active; it shows the object, the field values evaluated, and the value the profile actually contained, if V_VBAK_AAT is the one that failed it will show AUART in the checked-versus-authorised comparison. If SU53 is empty or ambiguous, run the authorisation trace (ST01, or the SU53 successor system trace on newer releases) around the exact click that fails, because a background job or IDoc scenario will not leave an SU53 buffer to read. Confirm the order type actually in play, VA02 in particular can mislead if the user thinks they are working an OR but the document was created as a ZOR variant. Hand the security team the user ID, the exact transaction, the AUART value from the document header, and the ACTVT attempted (create versus change matters, a role can have display-only on that type). Do not ask for AUART to be opened to * as a quick fix; ask for the specific type to be added to the existing value list.
Whose problem this is
This sits with security once the document type in question has been confirmed functionally. A good request names the user, the transaction, the exact AUART and ACTVT combination that failed, and states whether the type should be added permanently to the existing role or whether a new order type is being rolled out and needs adding to several roles at once.
Common pitfalls
- A role tested and working for standard orders fails the moment the business introduces a new document type (a new return type, a new intercompany order type) because AUART is a fixed value list, not a wildcard by default, and nobody remembered to extend it.
- Users conclude the sales area is wrong when V_VBAK_AAT fails, because the symptom, an order that will not open, looks identical whether it is the org-level object or the document-type object that blocked it; only SU53 tells the two apart.
- Copy control from quotation to order, or contract to order, fails at the target document type check even though the source document type is fully authorised, since the check runs on the AUART being created, not the AUART being read.
- IDoc-based order creation fails with no visible SU53 at all; the failure sits in the IDoc status record or the application log, and tracing it requires ST01 timed to the background processing window rather than a live user session.
- Granting ACTVT 02 without 03 causes an odd symptom where a user can open a document to change it but the initial display within the change transaction still errors, because some list views check display activity separately before the change screen loads.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/v-vbak-aatERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.