What Availability Control Is and Why Projects Depend On It
An introduction to Availability Control (AVAC) in SAP Project System: the business problem it solves, the core concepts of budget, actual, commitment and assigned values, and how tolerance-based warnings and errors protect project spending discipline.
Explanation
Every capital or customer project funded through SAP Project System carries a budget that stakeholders expect to be respected. Without an automated control, a project manager could keep releasing purchase orders or posting costs long after the approved budget is exhausted, and nobody would know until a period-end report surfaced the overrun. Availability Control (commonly abbreviated AVAC) exists to close that gap. It is a budgetary control mechanism built into the Project System (and also used in Investment Management and Internal Orders) that continuously monitors the relationship between the budget assigned to a WBS element (or project) and the values actually consumed against it, then reacts automatically based on rules you configure. To understand AVAC you first need to understand the values it compares. Budget is the amount formally released for the project or WBS element, usually entered and released through project budgeting transactions after approval workflows. Against that budget, the system accumulates 'assigned values', which typically include actual postings (invoices, goods receipts, cost postings), commitments (open purchase requisitions and purchase orders that have not yet been invoiced), and in some configurations, planned costs, depending on which value categories are included in the availability control check. The system expresses consumption as a percentage of budget and compares that percentage against tolerance limits you define, for example 90 percent triggers a warning, 100 percent triggers an error, or various combinations by budget type (original, supplement, return, transfer). When a document is posted or a commitment is created against a WBS element that has AVAC active, the system runs a background check at the moment of posting. If the resulting consumption crosses a warning threshold, the user typically sees a warning message but the transaction still completes. If it crosses an error threshold, the system blocks the posting entirely, and the user (or an approver, depending on process design) must either request additional budget, get budget released, or change the assignment before the transaction can proceed. This real-time enforcement is the key differentiator of AVAC compared to reactive, report-based budget monitoring: it prevents overspending before it happens rather than merely reporting it afterward. It is important for a beginner to understand that AVAC operates at the level of a controlling area and object type (project or WBS, internal order, and so on), and that it must be explicitly activated; it is not automatically switched on the moment budgets exist. Activation is tied to a budget profile and to specific tolerance limit configuration, which is why many new consultants are surprised the first time they enter a budget and post costs freely with no system reaction at all. Understanding that AVAC is a deliberately configured control, not an inherent property of budgeting, is the foundational mental model for everything else in this topic, including how it is designed, how it behaves during execution, and how it is troubleshot when it does not fire as expected. Finally, beginners should know that AVAC checks are influenced by the project's status. A project or WBS element must generally be released (and budgeted) for postings to be possible at all, and AVAC only becomes relevant once budget values exist to compare against. Understanding this status dependency avoids early confusion when a newly created WBS element accepts postings without any budget check simply because it has not yet been released or budgeted.
Real project scenario
On a plant capital expansion program, the PMO discovered midway through the fiscal year that several WBS elements had accumulated purchase orders well beyond their approved budgets, because Availability Control had not been switched on for that controlling area during initial project setup. Finance had assumed the system was blocking overspend automatically. The remediation involved retroactively activating AVAC, running the update program to rebuild assigned values, and then working through a cleanup exercise with project managers to either secure supplementary budget approvals or cancel unapproved commitments. This incident became the trigger for the customer to add an explicit AVAC activation checklist item to every new project system rollout.
Common mistakes
• Assuming budgeting a WBS element automatically enforces spending limits without confirming AVAC is activated for the relevant controlling area. • Not distinguishing between commitments, actuals and assigned values when explaining to project managers why a purchase requisition already impacts available budget. • Ignoring the impact of project or WBS status (not released, not budgeted) on whether AVAC checks even trigger. • Treating a warning message as equivalent to an error and not clarifying to end users that warnings do not block postings. • Failing to recognize that AVAC settings are tied to a budget profile, so different projects can behave differently if profiles are assigned inconsistently.
Best practices
• Always confirm with the customer's finance/PMO team what tolerance philosophy they want (strict blocking versus soft warnings) before configuring AVAC. • Explain the distinction between commitments and actuals to project managers early, since commitments often surprise them by consuming budget before invoices are posted. • Document, for each controlling area, whether AVAC is active and at which tolerance levels, as part of standard project system setup documentation. • Verify WBS release and budget status whenever a stakeholder reports that 'the system let me overspend', since an unreleased or unbudgeted WBS element will not trigger AVAC. • Use AVAC together with reporting (not as a replacement for it), since some value categories or exempted cost elements may not be included in the check.
Interview angle
Interviewers commonly ask candidates to explain, in plain business terms, what problem Availability Control solves and to differentiate warning versus error tolerance behavior. Strong answers connect AVAC to real budgeting governance (why finance teams require it), describe the values compared (budget versus actual plus commitment), and show awareness that AVAC must be actively configured and activated rather than being a default system behavior.