V_VBRK_VKO — Billing Document Sales Area Authorization
V_VBRK_VKO controls create, change and display access to billing documents based on the sales area (sales organization, distribution channel, division) stored on the billing document header, checked in VF01, VF02, VF03 and mass billing runs. Failures typically happen because the billing document's sales area differs from the sales order's sales area, not because the role is missing.
This page covers what V_VBRK_VKO guards during billing document creation, change and display, the fields it checks, and where in the billing process SAP triggers the check. It focuses on tracing a failed check and the recurring reason a role that grants sales order access still fails at the billing step.
Published 16 Sept 2026· 879 words
What it protects
V_VBRK_VKO guards create, change and display of billing documents (invoices, credit memos, debit memos, pro forma) at the sales area level: sales organization, distribution channel, division. The structural fact behind most confusion is that this check runs against the sales area stored on the billing document header itself, not against the sales area of the sales order or delivery it was created from. A billing document's sales area is derived once, at creation, from the reference document, but in intercompany billing, cross-company stock transfer billing, or certain credit memo processes, the billing sales area can differ from the sales area of the order or delivery. A user with full access to the originating sales order can therefore still be blocked at VF01 because the billing document lands in a sales area the role never covers.
Fields checked
- VKORG - sales organization recorded on the billing document header; restricts which company's billing documents the user can touch.
- VTWEG - distribution channel on the billing document header; often a source of gaps because it is maintained inconsistently across roles compared to VKORG.
- SPART - division on the billing document header; frequently the field left with a narrower value list than the business actually bills against.
- ACTVT - activity being performed: 01 for create, 02 for change, 03 for display. A role with 03 but not 01/02 will let a user open a billing document but not post or cancel it.
Where it is checked
- VF01 - create billing document, checked against the derived sales area at the point the document is saved, with activity 01.
- VF02 - change billing document, activity 02, checked when the document is opened for edit and again on save.
- VF03 - display billing document, activity 03, checked when the document is opened.
- VF04 / VF06 - billing due list processing and background billing runs; each document generated is checked individually, and failures here are easy to miss because the job continues and simply skips the blocked documents rather than stopping.
- VF11 - cancellation of a billing document, checked with change-equivalent activity against the sales area of the document being cancelled.
- Billing triggered from delivery-related or order-related background processes (IDoc inbound, BAPI-driven billing) hits the same check silently; there is no interactive SU53 opportunity unless the job user's session is traced separately.
How to trace a failed check
Start with SU53 run by the affected user immediately after the failed VF01/VF02/VF03 attempt; it shows the object, the field values checked, and which value was missing from the role - but only for the last failed check in that session, so it is unreliable for VF04 mass runs or background jobs. For those, ask security to start an authorization trace (ST01 or the STAUTHTRACE variant) filtered on the user ID and the object V_VBRK_VKO before rerunning the transaction, then stop and review the trace entries. Before escalating, open the specific billing document (or the order/delivery it was generated from) and read off its actual VKORG, VTWEG and SPART values - do not assume they match the sales order. Hand security the user ID, the exact sales area values from the billing document, the activity attempted (create, change, display, cancel), the transaction or batch job name, and the timestamp. Vague reports of 'billing is broken' without the document's actual sales area send security down the wrong path.
Whose problem this is
Fixing the role is a security task, but identifying the correct sales area combination is functional. A good request to security names the user, the billing document sales area (not the order's), the activity, and whether the gap is a single missing division/channel or a whole missing sales organization, so security can decide between widening an existing value range and creating a new authorization line.
Common pitfalls
- Assuming the billing document inherits the sales order's sales area exactly; intercompany billing, plant-to-plant stock transfer billing, and some credit memo request flows assign a different sales organization or division to the billing document.
- Fixing the role by copying the sales order's sales area values into the billing role without checking what the billing document actually carries, which fixes nothing and wastes a cycle with security.
- Blaming the billing type or document type when the real block is the sales area field, because SU53 output for a rejected billing type check can look superficially similar.
- Overlooking that VF04 background runs execute under a batch or proxy user whose authorizations differ from the requesting user's own role, so the interactive user's SU53 shows no problem while the job silently drops documents.
- Maintaining VKORG with the correct value but leaving VTWEG or SPART restricted to a narrower list than the business processes, so only some billing documents in the same sales organization fail.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/v-vbrk-vkoERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.