B2R Control Workbench
Design a business-readable B2R control model that answers: what object am I controlling, what authority exists, what consumed it, what changed, and can we explain what remains and why?
CONTROL OBJECT AXIS
Which object am I controlling?
These rails are not maturity stages. They are different cost-control objects selected according to the business question. A manufacturing company may simultaneously use cost centers, internal orders, WBS elements, and production orders.
| Rail | Object family | Use when |
|---|---|---|
| Rail 1 — Overhead Control | Cost Center + Internal Order | Recurring departmental or functional control, responsibility-center spending, and temporary initiatives that need their own cost collector. |
| Rail 2 — Project / Capital Control | WBS + Network where applicable | Projects, capital programs, controlled project budgets, and multi-level project cost structures. |
| Rail 3 — Production Cost Control | Production Order | Manufacturing order cost, production execution cost, actual versus standard or target cost, variance, and settlement. |
CONTROL LIFECYCLE AXIS
How does control flow?
The same lifecycle can apply to different control objects. Keep object selection separate from lifecycle stage.
What do we expect?
Working plan, expected cost, activity, drivers, and responsibility.
What may we consume?
Approved authority, budget category/profile, activation, and object-specific control basis.
What have we promised?
Purchase requisitions, purchase orders, contracts, and project commitments where applicable.
What has actually been spent?
Invoices, payroll, project postings, journals, goods movements, confirmations, and reversals.
What authorization changed?
Transfer, supplement, return, rephase, cancellation, correction, or emergency exception.
What remains available and why?
Original budget, approved changes, commitments, actuals, reversals, remaining amount, and accounting tie-out where required.
PLAN / BUDGET / FORECAST
Do not use these terms interchangeably
PLAN asks what we expect to happen. BUDGET asks what we are authorized to consume. FORECAST asks, based on current reality, where we now expect to land.
Expected Cost / Activity
Approved Spending Authority
Latest Expected Outcome
ADDITIVE RAILS
Choose the object from the control question
Budget Availability Control is a control layer, not Rail 2 by itself. The business principle is common, but the SAP implementation mechanism depends on the controlling object.
Cost Centers
Internal Order
WBS
Production Order
OBJECT-AWARE AVAILABILITY CONTROL
Same control principle, different SAP mechanism
CONTROL POLICY: Budget → Consumption → Threshold → Warning / Block / Escalation.
Cost Center Budget Availability Control
For selected S/4HANA scenarios, approve and make available a controlled cost-center budget, then activate availability control with the appropriate profile.
Internal Order Availability Control
Use the order type, budget profile, budget, and availability control design for temporary controlled activity.
Project / WBS Availability Control
Use the project profile, budget profile, budget, optional release, and availability control where the project model requires it.
DOMAIN BOUNDARY
Keep FP&A, B2R, and R2R distinct
FP&A owns forward-looking plan and forecast. B2R owns spending authority, commitment, and consumption control. R2R owns accounting truth, reconciliation, and close.
Forward outlook, scenarios, and expected landing position.
Spending authority, commitment, consumption, change governance, and availability.
Financial accounting truth, close controls, and reporting reconciliation.
SAP ARCHITECTURE NOTE
Keep planning state separate from technical versioning
Business planning states and SAP technical versions/categories are related, but they are not automatically the same thing. A solution can combine CO versions, plan categories, budget categories, ACDOCP, SAC versions or scenarios, and workflow status.
Authorize spending, track consumption, apply availability checks, and report accountable action.
FP&A owns forward-looking scenarios; R2R owns close and financial reporting; B2A owns capitalization; P2M owns manufacturing execution.
CONTROL DESIGN
Select control object
Which object owns responsibility and reporting? Choose the object family before designing budget checks, settlement, or reporting.
Maintain in order
- Choose Cost Center for recurring responsibility spending and Internal Order for temporary initiative cost that needs its own collector.
- Choose WBS and Network where applicable for project or capital structures.
- Choose Production Order for manufacturing cost, actual versus standard or target cost, variance, and settlement.
Check controlling-area assignment, object status, validity, account assignment, master-data ownership, and whether the posting is real or statistical.
CONTROL DESIGN
Plan, budget, and forecast
What is expected, what is authorized, and where do we now expect to land? Do not use the three terms interchangeably.
Maintain in order
- PLAN: record expected cost, activity, drivers, timing, and responsibility.
- BUDGET: load or approve the controlled authority and activate availability control where the selected object uses it.
- FORECAST: refresh the latest expected outcome without silently changing approved authority.
Check budget category or profile, object assignment, fiscal-year scope, currency, activation, approval evidence, and whether project release is required by the selected profile.
CONTROL DESIGN
Availability control
What counts as consumption, what threshold applies, and which SAP mechanism applies to this object?
Maintain in order
- Use the business policy Budget → Consumption → Threshold → Warning / Block / Escalation.
- Use object-specific implementation: Cost Center Budget Availability Control, Internal Order Availability Control, or Project / WBS Availability Control.
- Test positive, warning, and blocking cases with the correct controlled object. Do not assume every source event is relevant in every edition or configuration.
Check account groups or cost items, commitment-update settings, transaction coverage, tolerance profile, object status, reversal, and period cut-off.
CONTROL DESIGN
Commitments and actuals
Which source events consume authority, and does commitment convert to actual without double-counting?
Maintain in order
- Define commitment treatment for purchase requisitions, purchase orders, contracts, and project commitments.
- Define actual-cost treatment for invoices, payroll, journals, goods movements, project postings, confirmations, and reversals.
- Prove that one business event changes availability once and reverses correctly.
Check source document, real collector, activity type or material movement, object status, period-end sequence, technical version/category, and posting reversal.
CONTROL DESIGN
Change governance
What authority changed, who approved it, and can the before/after position be explained?
Maintain in order
- Separate SAP budget changes such as transfer, supplement, return, and rephase from business governance such as approval, reason, owner, audit trail, and exception authority.
- Do not imply that every organization performs the business approval workflow inside S/4.
- Prove original budget, approved change, updated available budget, actual and commitment history, and reason evidence.
Check change type, approval evidence, source/receiver object, effective period, currency, existing consumption, audit reason, and emergency exception authority.
CONTROL DESIGN
Reconciliation and handoff
Can management explain what remains and why? Report the authority and consumption position without converting the workbench into FP&A or R2R.
Maintain in order
- Reconcile approved authority, approved changes, commitments, actual consumption, reversals, and remaining availability.
- Define the R2R accounting tie-out where required and the FP&A forecast handoff without duplicating their detailed process designs.
- Show Budget → Commitment → Actual → Available → Variance → Action, with the accountable manager and source evidence for each material exception.
Check object selection, fiscal period, hierarchy, currency, plan/budget category, commitment inclusion, close status, report refresh, reconciliation totals, and action ownership.
COMMITMENT MENTAL MODEL
One event should change availability once and reverse correctly
BUDGET - COMMITMENTS - ACTUALS + REVERSALS / RETURNS = AVAILABLE. Treat it as a control mnemonic; exact mechanics vary by object.
Budget Available → Create PR → Commitment Created → Convert to PO → Commitment Updated → Post Invoice → Actual Created → Commitment Reduced / Cleared → Available Budget Reconciled
Original Budget → Approved Transfer / Supplement / Return → Updated Available Budget → Audit / Reason Evidence → Reconcile Before and After
Approved Authority → Commitments → Actual Consumption → Changes → Remaining Availability
TRANSPORT AND DATA BOUNDARIES
Do not blur configuration and budget execution
Keep Customizing, governed master data, and transaction/control data visibly separate.
- Customizing: BAC profiles, tolerance limits, budget categories where applicable, object-specific control settings, settlement configuration, activation, and profile design.
- Master / governed data: Cost Center, Internal Order master, WBS, Network, Production Order reference configuration where relevant, responsible person, hierarchy, and planning or budget master structures.
- Transaction / control data: plan values, budget values, commitments, actual postings, transfer, supplement, return, reversal, settlement, and availability-control consumption.
END-TO-END PROOF
Prove Rail 1 first, then add object extensions only where needed
Temporary initiatives can collect cost on an internal order and settle to the agreed receiver. The minimum example in this guide settles to a cost center.
Rail 1 vertical slice
Create or select a Cost Center, load the approved controlled budget, create an Internal Order for a temporary initiative, create a commitment, post an actual, reverse or correct one event, settle the order to the agreed receiver, and reconcile budget, commitment, actual, and availability.
Threshold proof
Approach or exceed the configured control threshold and prove the expected warning, block, or escalation for the selected object and profile.
Rail 2 extension
For project/capital scope, prove WBS budget, commitment, actual, availability control, and settlement or capitalization handoff without turning the guide into a full PS design.
Rail 3 extension
For production scope, prove Production Order planned or target cost, actual consumption, variance, and settlement without turning the guide into a full PP/Product Costing design.
PRACTITIONER MNEMONIC
Plan, budget, commit, consume, change, reconcile
PLAN What do we expect? BUDGET What may we consume? COMMIT What have we promised? CONSUME What has actually been spent? CHANGE What authority changed? RECONCILE What remains, and why?
FINAL PRINCIPLE
One Controlled Object, One Explainable Remaining Budget
Control is complete only when the approved authority, commitments, actual consumption, changes and remaining availability can be explained for the selected controlling object and reconciled to the underlying accounting result where required.
Settings are not evidence.
Use policy workshops, pilot evidence, cutover, first cycle, and stabilization.