SAP Availability Control Tutorial (Part 1)

📌 KEY POINTS
✅ AVAC compares assigned value (actuals + open commitments) against approved budget on a WBS element, reacting BEFORE overspend happens.
✅ Budget = formally released spending authority. Assigned value = actual postings + open commitments (unbilled POs/PRs), depending on which value categories the check includes.
⚠️ AVAC is NOT automatic — a newly budgeted WBS with no activation accepts postings with zero system reaction.
💡 The WBS/project must also be released and budgeted before checks are relevant at all.

━━━━━━━━━━━━━━━━━━━━
▶ 1. WHAT AVAC COMPARES

• Assigned value vs approved budget, expressed as a percentage
• Compared against tolerance limits by budget type: original, supplement, return, transfer
• Typical thresholds: warning around 80–90%, error stop at 100%

━━━━━━━━━━━━━━━━━━━━
▶ 2. WHY IT'S NOT AUTOMATIC

• Requires activation at controlling-area/object-type level
• Tied to a budget profile, plus explicit tolerance limit configuration
• A common source of early-project confusion: budget exists, but zero enforcement until activated

✅ CHECKPOINT: you can explain why a WBS with budget assigned might still allow unlimited overspend.

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.

• 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.

• 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.

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.