Configuring Tolerance Limits and Activating Availability Control
A practical walkthrough of configuring Availability Control for SAP Project System: defining tolerance limits by budget type and action, activating AVAC per controlling area and budget profile, and verifying the configuration through test postings.
Explanation
Configuring Availability Control is a multi-step exercise that ties together budget profile settings, tolerance limit definitions, and controlling-area-level activation. Getting the sequence right, and understanding how each piece influences runtime behavior, is essential for a PS consultant responsible for project budgeting design. The starting point is the budget profile assigned to the project type you are configuring. The budget profile determines several behaviors relevant to AVAC, including whether availability control is even relevant for projects using that profile, what currency and value type rules apply, and whether budgeting is done at the project definition level, WBS level, or both. Before touching tolerance limits, confirm which budget profile the customer's projects use and that AVAC-relevant settings on that profile point in the direction the business wants. Next, tolerance limits are defined at the level of controlling area, and they specify, for each combination of budget type (original budget, budget supplement, budget return, budget transfer) and each usage (percentage of budget consumed), what action the system should take: a warning to the person posting, a warning sent as a workflow-style notification to a responsible person, or an error that blocks the document. A typical configuration defines a graduated set of thresholds, for example a warning at 80 percent triggered to the person entering the transaction, a second warning at 90 percent routed to the person responsible for the project, and a hard error at 100 percent that blocks further postings across all document types (purchase requisition, purchase order, goods receipt, invoice, and internal activity allocation, among others). You can also scope tolerance limits so that certain document categories are excluded from the check if the business wants, for example, purchase requisitions to only warn while purchase orders enforce a hard stop. Once tolerance limits exist, Availability Control must be explicitly activated for the controlling area (and, depending on configuration approach, for individual projects if activation is done at project level rather than blanket controlling-area level). Activation triggers the system to build the initial assigned-value totals from existing budget and postings; on projects that already have historical postings, this activation step effectively performs a recalculation so that AVAC has an accurate baseline to compare against going forward. This is a critical operational point: activating AVAC on a project with years of history requires the update/rebuild step to run cleanly, and consultants should expect this to take noticeable processing time on data-heavy controlling areas, and should schedule it outside of heavy transactional periods when working in a production-like environment. After activation, verification should never be skipped. A disciplined approach is to select a test WBS element with known budget and known committed/actual values, calculate manually what percentage of budget is consumed, and then post a small transaction (for example, a low-value purchase requisition) that should cross a warning threshold, confirming the expected message appears. Repeat with a transaction sized to cross the error threshold and confirm the system blocks it. This test-driven verification catches common misconfigurations such as tolerance limits defined against the wrong budget type, or activation scoped to the wrong controlling area. Finally, consultants must understand that AVAC configuration interacts with derivation and status management. Certain user statuses can be configured to bypass or force checks, and certain cost elements can be excluded from the value categories considered 'assigned value' for AVAC purposes if that exclusion is part of the customer's design. Documenting these exceptions clearly prevents future confusion when postings behave inconsistently across seemingly similar WBS elements.
Real project scenario
During a fit-gap workshop for a construction industry client, the finance lead requested that purchase requisitions only issue a soft warning while purchase orders and invoices strictly block once 100 percent of budget is reached, so that procurement teams could still plan ahead without hard blocking early in the sourcing cycle. The consultant configured differentiated tolerance limits by document category, activated AVAC for the relevant controlling area, and then ran a structured test cycle across a sample WBS element covering requisition, purchase order and invoice postings at 85 percent, 95 percent and 105 percent of budget consumption to confirm each threshold produced the agreed behavior before promoting the configuration to the production-support environment.
Common mistakes
• Defining tolerance limits against the wrong budget type (for example, only original budget) and forgetting that supplements or transfers also need explicit tolerance entries. • Activating Availability Control without running or verifying the update/rebuild of assigned values, leading to inaccurate initial consumption percentages. • Assuming activation at controlling area level automatically applies retroactively to every project without checking project-level or profile-level overrides. • Skipping structured test postings after configuration changes, only discovering gaps when end users report unexpected blocking or unexpected lack of blocking in production. • Not documenting which document categories or cost elements are excluded from the AVAC check, causing confusion when two similar WBS elements behave differently.
Best practices
• Confirm budget profile settings and value categories with the finance team before defining tolerance limits, since the profile shapes what AVAC can and cannot enforce. • Design tolerance limits with graduated warnings before the hard error threshold so project teams have visibility before being blocked. • Always run a rebuild/update of assigned values immediately after activating AVAC on projects with existing postings, and confirm totals reconcile with expected budget consumption. • Execute a structured test plan (below warning, above warning, above error) on a representative WBS element before promoting AVAC configuration changes to production. • Maintain a configuration decision log documenting which document categories, cost elements or statuses are excluded from AVAC checks, to support future troubleshooting.
Interview angle
Interviewers assessing configuration depth often ask candidates to describe the exact sequence of steps to activate AVAC for a new controlling area and to explain what happens to existing postings when AVAC is activated after data already exists. A well-rounded answer covers budget profile prerequisites, tolerance limit definition by budget type and usage, controlling-area activation, the rebuild of assigned values, and a verification test plan, showing the candidate treats configuration as a testable, reversible exercise rather than a one-time setting.