WBS

WBS Project Budget Control

Client Solution Documentation

AEC WBS Project Budget Control Solution

A controlled framework for WBS creation, budget allocation and transfer, transaction tagging, and commitment-versus-release reporting.

Primary Focus

• WBS creation and grouping
• Budget allocation
• Transaction-level WBS control

Control Focus

• Budget transfer
• WBS reporting
• Commitment and release monitoring

1. Executive Overview

The solution establishes the Work Breakdown Structure (WBS) as an accounting dimension for project control.

It connects:

• Project planning
• Budget authorization
• Procurement commitments
• Delivered-cost actuals
• Journal entries
• Management reporting

into one traceable process.

Business Purpose

Prevent uncontrolled project spending while giving Finance and project teams a real-time view of:

• Budget
• Release
• Commitment
• Actual
• Remaining availability

at WBS level.

What the Client Receives

1. A hierarchical WBS master with root, group, and executable leaf elements.
2. Budget and release allocation at the lowest actionable WBS level.
3. WBS selection within Accounting Dimensions for purchase orders, delivery notes, journal entries, and other applicable transactions.
4. Controlled transfer of available budget with sender and receiver history.
5. A WBS report comparing release, commitment, actual, and remaining values.

End-to-End Control Cycle

Structure → Fund → Consume → Monitor

Scope Principles

• Group nodes organize the project.
• Leaf nodes hold spendable budget and release.
• Commitment is created from purchase orders.
• Commitment remains visible until the related quantity is delivered or the purchase order is cancelled.
• Actuals are posted to the selected WBS through operational and accounting transactions.

2. WBS Creation and Group Structure

The WBS is maintained as a tree-type master.

Each project begins with:

1. A root WBS
2. One or more group levels
3. Leaf WBS elements used for budgeting and transaction control

WBS Hierarchy

Numbering Rule

The root code is provided when the project is created.

Child codes are generated automatically from the parent path and should remain read-only to preserve hierarchy and reporting integrity.

Important: Budget and Release values are available only for WBS elements where Is Group is not selected.

3. WBS Creation Procedure and Governance

Creation Procedure

1. Create the root WBS using the approved project code and project name.
2. Create parent WBS elements for major phases, disciplines, or control groups and select Is Group.
3. Create leaf WBS elements under the correct parent and leave Is Group cleared.
4. Confirm the placement path and automatically generated WBS code.
5. Assign the approved Budget and Release to each leaf WBS.
6. Test that the WBS appears in the relevant transaction selection list and WBS report.

Recommended Segregation of Duties

Security Principle

Access should be granted through role-based permissions.

User credentials and passwords must never appear in client-facing documentation or operating procedures.

4. Budget Allocation and Release Control

Budget represents the approved ceiling for a leaf WBS.

Release represents the authorized portion currently available for commitment and actual posting.

A WBS may have a budget but must not be used for controlled spending until an appropriate release is provided.

Financial Measures

Core Validation Rules

1. Release must not exceed Budget.
2. A WBS without Budget or Release is blocked from controlled purchase-order selection.
3. The system rechecks available release whenever a new commitment or actual is created.
4. An earlier approval does not bypass the next validation.
5. Only active leaf WBS elements can be selected for spending transactions.

5. Journal Entries and Transaction Integration

WBS is configured as an Accounting Dimension.

When a transaction line relates to the project, the user opens the Accounting Dimensions area, selects the related WBS, and completes the posting.

This creates a consistent link between:

• Operational activity
• General-ledger entries
• Project reporting

Journal Entry Workflow

1. Create the journal entry and open the required accounting row.
2. Expand or open Accounting Dimensions for that row.
3. Select the project WBS from the WBS field.
4. Review the WBS budget and release context before submission.
5. Submit the entry.

The amount becomes an actual against the selected WBS according to the configured posting logic.

Applicable Transactions

The same WBS dimension can be used on:

• Purchase Orders
• Delivery Notes
• Journal Entries
• Purchase Invoices
• Payment Entries
• Sales Documents
• Stock Entries

The exact transaction types depend on the system configuration.

Important: Mandatory-versus-optional WBS selection should follow the approved business rule because not every accounting entry is necessarily project-related.

6. Budget Transfer

Where a WBS or completed project retains unused available budget, an authorized user can transfer an approved amount to another receiving WBS.

This supports reallocation from an earlier project to a new project when cross-project transfer is enabled by policy and approval.

Otherwise, the transfer is restricted to WBS elements under the same top-level project.

Client Governance Decision

The client must confirm whether production transfers are:

• Allowed only within one project, or
• Allowed between different projects.

If cross-project transfers are permitted, they should require stronger approval and reporting.

Transfer Procedure

1. Open the sending WBS and click Transfer Budget.
2. Choose the receiving WBS.
3. The system validates that the receiving WBS is active and eligible.
4. Enter the transfer amount.
5. Enter a clear business justification in Remarks.
6. Validate that the amount does not exceed the sender's transferable balance.
7. Confirm the transfer.
8. The sender decreases and the receiver increases by the same amount.
9. Review the outgoing and incoming records in Budget Transfer History.

7. Budget Transfer Audit Trail

Every transfer is recorded against both WBS elements.

The receiving WBS shows the entry as Incoming.

The sending WBS shows the same transaction as Outgoing.

The shared reference creates a complete audit trail for Finance review.

Transfer History Fields

Transfer Control Checks

Transferable balance should exclude:

• Committed amounts
• Actual exposure

The transfer operation should be:

• Permission-controlled
• Amount-validated
• Timestamped
• Non-deletable through normal user access

8. WBS Report: Commitment vs Release

The WBS Report is the primary management view.

It should present the hierarchy and financial position for each WBS so project and Finance users can identify:

• Overspend risk
• Unused release
• Amounts available for transfer

Report Columns

Illustrative WBS Report

Management Interpretation

Commitment + Actual = 20,000

Against a 30,000 Release:

30,000 − 20,000 = 10,000 Available Release

Against a 50,000 Budget:

50,000 − 20,000 = 30,000 Budget Balance

However, only the released portion may be used without further authorization.

Note: The example values are illustrative only. Currency and values should follow the project's approved budget baseline and transaction data.

Commitment Lifecycle

1. Purchase Order Submitted

Commitment increases.

2. Project Delivery Recorded

The delivered portion moves from Commitment to Actual.

3. Purchase Order Cancelled

The remaining commitment is released back to availability.

4. Journal or Other Direct Posting

Actual increases on the selected WBS.

9. Technical Completion, Controls, and Demonstration

Technical Completion

When Is Completed (Technical Completion) is selected:

• The WBS should no longer appear in transaction selection lists.
• No further entries should be posted.

Before completion, the team should:

1. Resolve or cancel open purchase orders.
2. Transfer any genuinely unused budget that requires reallocation.
3. Confirm that the WBS no longer requires additional transactions.

Important System Behavior

Open commitment is sourced from purchase orders.

Technical completion does not automatically reset commitment to zero.

The responsible purchase order must be:

• Delivered
• Closed, or
• Cancelled

according to business policy.

10. Recommended Client Demonstration

The following demonstration is recommended during client acceptance.

1. Create a root WBS.

2. Create one group WBS.

3. Create one leaf WBS.

4. Allocate Budget and Release to the leaf WBS.

5. Show that group nodes do not hold spendable values.

6. Create a Purchase Order and select the WBS in Accounting Dimensions.

7. Show the validation when Release is missing.

8. Open the WBS report.

9. Show:

   • Release
   • Commitment
   • Actual
   • Available Release

10. Transfer an approved amount to a receiving WBS.

11. Show the Incoming and Outgoing transfer history.

12. Post a Journal Entry linked to the WBS.

13. Confirm the report update.

14. Mark the WBS technically complete.

15. Confirm that the WBS is no longer selectable.

11. Acceptance Criteria

12. Client Decisions to Confirm

The following decisions must be confirmed with the client before production rollout:

1. Whether cross-project budget transfers are permitted.
2. What approval level is required for cross-project transfers.
3. Which transaction types require WBS selection.
4. Which transaction types should keep WBS selection optional.
5. The exact point at which operational delivery becomes a financial actual for each transaction flow.
6. Tolerance and escalation rules when Commitment + Actual approaches or exceeds Release.

Summary

The AEC WBS Project Budget Control solution provides a controlled project accounting framework based on the Work Breakdown Structure.

The overall process is:

Create WBS → Allocate Budget → Release Budget → Tag Transactions → Track Commitments → Record Actuals → Transfer Available Budget → Monitor WBS Report → Complete WBS

The objective is to ensure that every project-related commitment and actual entry can be traced to the correct WBS, checked against its released budget, and supported by a complete budget-transfer audit trail.