# Cost Allocation

## Overview

Cost Allocation is the process of distributing overhead costs from sender cost centers to receiver cost objects (cost centers, profit centers, or internal orders) using configurable allocation cycles and rules. The module supports two distinct allocation methods: assessment, which posts using secondary cost elements (aggregating the original cost elements into a single overhead category on the receiver), and distribution, which preserves the original primary cost elements on the receiver side for full cost transparency.

An allocation cycle groups a set of allocation rules, each defining a sender cost center, one or more receiver cost objects, and the allocation basis (fixed percentage or amount-based factor). Cycles progress through a controlled lifecycle — DRAFT, VALIDATED, EXECUTED, POSTED, and optionally REVERSED — ensuring that allocations are reviewed and tested before they affect the general ledger. Execution first runs in test mode to preview results, then in actual mode to generate immutable allocation result records. Posting creates journal entries through the finance-ledger subledger integration pattern, and corrections are handled exclusively via reversal and re-posting, never by deletion.

## Business Purpose

Organizations need a structured cost allocation mechanism to accurately assign indirect and overhead costs to the business areas that consume them:

- **Overhead cost distribution**: Shared service costs (IT, facilities, HR) must be allocated to the operating units that benefit from them, enabling accurate product and service costing
- **Assessment vs distribution flexibility**: Assessment simplifies receiver-side reporting by consolidating costs under secondary cost elements, while distribution preserves original cost element detail for granular cost analysis — organizations choose based on their reporting requirements
- **Allocation rule governance**: Configurable rules with percentage-based or factor-based allocation bases ensure that cost distribution reflects actual resource consumption or agreed-upon sharing ratios
- **Percentage completeness validation**: Allocation rules for a given sender must have receiver percentages summing to exactly 100%, preventing under- or over-allocation of costs
- **Test run capability**: Executing an allocation cycle in test mode allows controllers to review projected results before committing actual postings, reducing the risk of errors in the general ledger
- **Immutable audit trail**: Allocation results are recorded as immutable records linking cycle, sender, receiver, allocated amount, and cost element, satisfying internal control and external audit requirements
- **Correction via reversal**: Posted allocations cannot be modified or deleted — corrections require reversing the entire cycle and re-executing with corrected rules, preserving full traceability of all cost movements
- **Period and company scoping**: Allocation cycles are scoped to a specific company and accounting period, ensuring that cost distributions align with the correct reporting boundaries
- **Ledger integration**: Allocation postings flow through the finance-ledger journal entry system, maintaining consistency between the cost accounting subledger and the general ledger

## Process Flow

```mermaid
stateDiagram-v2
    [*] --> Draft: createAllocationCycle
    Draft --> Draft: updateAllocationCycle / addAllocationRule / removeAllocationRule
    Draft --> Validated: validateAllocationCycle
    Validated --> Draft: invalidateAllocationCycle
    Validated --> Executed: executeAllocationCycle (ACTUAL)
    Executed --> Posted: postAllocationCycle
    Posted --> Reversed: reverseAllocationCycle
```

```mermaid
flowchart TD
    A[Define allocation cycle with type and period] --> B[Add allocation rules: sender, receivers, percentages]
    B --> C{All sender rules sum to 100%?}
    C -- No --> D[Adjust rule percentages]
    D --> B
    C -- Yes --> E[Validate allocation cycle]
    E --> F[Execute in TEST_RUN mode]
    F --> G{Review test results acceptable?}
    G -- No --> H[Return to DRAFT and adjust rules]
    H --> B
    G -- Yes --> I[Execute in ACTUAL mode]
    I --> J[Immutable AllocationResult records created]
    J --> K[Post allocation cycle]
    K --> L{Assessment or Distribution?}
    L -- Assessment --> M[Create journal entries with secondary cost elements]
    L -- Distribution --> N[Create journal entries preserving original cost elements]
    M --> O[Journal entries posted via finance-ledger]
    N --> O
    O --> P[Allocation complete]
```

```mermaid
flowchart TD
    A[Select posted allocation cycle to reverse] --> B[Create reversal journal entries with inverted amounts]
    B --> C{Reversal period OPEN or FUTURE_ENTERABLE?}
    C -- No --> D[Select valid reversal period]
    D --> C
    C -- Yes --> E[Post reversal entries via finance-ledger]
    E --> F[Allocation cycle status set to REVERSED]
    F --> G[Original allocation amounts offset to zero]
```

## Scenario Patterns

- **IT Department Overhead Assessment**: The IT cost center incurs infrastructure and support costs that serve multiple business units. An assessment cycle allocates these costs to the Sales, Manufacturing, and R&D cost centers using secondary cost element "IT Overhead Assessment" with fixed percentages (40%, 35%, 25%). Receivers see a single aggregated IT overhead line rather than individual cost element details
- **Facilities Cost Distribution**: Building maintenance, utilities, and security costs from the Facilities cost center are distributed to three profit centers based on floor space ratios. Distribution method preserves the original cost elements (rent, electricity, cleaning) on the receiver side, enabling profit center managers to see the detailed breakdown of facility costs they are consuming
- **Shared Services Assessment to Internal Orders**: A central HR shared services cost center allocates recruitment and training costs to project-based internal orders using assessment. Each internal order receives an overhead charge under a secondary cost element, enabling project managers to see the total loaded cost of their initiatives
- **Multi-Receiver Percentage Allocation**: A logistics cost center distributes warehousing costs to five regional profit centers using percentages derived from order volume (30%, 25%, 20%, 15%, 10%). The controller validates that percentages total 100%, runs a test execution to verify amounts, and then executes and posts the actual allocation
- **Test Run Review and Adjustment**: A cost controller sets up an allocation cycle for administrative overhead but notices during the test run that one receiver cost center has been decommissioned. The controller returns the cycle to DRAFT, updates the rules to redirect that portion to the successor cost center, re-validates, and executes again
- **Allocation Reversal and Correction**: After posting a quarterly assessment cycle, a controller discovers that the allocation percentages were based on outdated headcount data. The controller reverses the posted cycle, creates a new cycle with corrected percentages, validates, executes, and posts the corrected allocation — both the original and corrected postings remain in the ledger for full auditability
- **Period-End Overhead Allocation**: At month-end close, the accounting team executes multiple allocation cycles to distribute all overhead cost centers before generating management reports. Each cycle targets the current accounting period and is posted sequentially to ensure dependent allocations (e.g., secondary cost centers that received allocations themselves) are captured correctly

## Test Cases

- Allocation cycle lifecycle follows DRAFT -> VALIDATED -> EXECUTED -> POSTED state machine; posted cycles can transition to REVERSED
- Allocation cycle can only be created in DRAFT status
- Allocation cycle requires a valid type (ASSESSMENT or DISTRIBUTION)
- Allocation cycle requires a valid name
- Allocation cycle must reference a valid companyId; the company must be in ACTIVE status
- Allocation cycle must reference a valid accounting period
- Allocation rules can be added to or removed from a DRAFT allocation cycle
- Allocation rules cannot be added to or removed from a VALIDATED, EXECUTED, POSTED, or REVERSED cycle
- Each allocation rule must reference a valid sender cost center
- Each allocation rule must reference a valid receiver cost object (cost center, profit center, or internal order)
- A sender cost center cannot also appear as a receiver within the same allocation rule set
- Allocation rule percentages for a given sender must sum to exactly 100%
- Allocation rules with percentages not summing to 100% for any sender cause validation to fail
- Allocation rule percentage values must be positive (greater than zero)
- Validating a DRAFT cycle with valid rules transitions its status to VALIDATED
- Validating a cycle with no allocation rules fails
- A VALIDATED cycle can be returned to DRAFT for further editing
- Executing an allocation cycle in TEST_RUN mode generates preview results without changing cycle status to EXECUTED
- Executing an allocation cycle in ACTUAL mode transitions its status from VALIDATED to EXECUTED
- Execution in ACTUAL mode creates immutable AllocationResult records for each sender-receiver-amount combination
- AllocationResult records cannot be modified or deleted after creation
- Each AllocationResult references the allocation cycle, sender, receiver, allocated amount, and cost element used
- Executing a cycle that is not in VALIDATED status fails with an invalid status transition error
- Posting an EXECUTED cycle creates journal entries through the finance-ledger subledger integration
- Assessment-type allocation postings use secondary cost elements in the generated journal entries
- Distribution-type allocation postings preserve the original primary cost elements in the generated journal entries
- Posting transitions the cycle status from EXECUTED to POSTED
- Posting a cycle that is not in EXECUTED status fails with an invalid status transition error
- Journal entries created by posting reference the allocation cycle as the source document
- Reversing a POSTED cycle creates reversal journal entries with inverted amounts
- Reversal transitions the cycle status from POSTED to REVERSED
- Reversing a cycle that is not in POSTED status fails with an invalid status transition error
- Reversal journal entries must target a period that is in OPEN or FUTURE_ENTERABLE status
- A REVERSED cycle cannot be reversed again
- Allocation cycles are scoped to a company; cycles from different companies are fully isolated
- Allocation cycles reference a specific accounting period; the period must be in OPEN or FUTURE_ENTERABLE status for posting
- Posting an allocation cycle to a CLOSED or PERMANENTLY_CLOSED period is rejected
- Updating allocation cycle fields (name, rules) is only permitted while the cycle is in DRAFT status
- Deleting an allocation cycle is only permitted while in DRAFT status
- Creating an allocation cycle emits an audit event recording the acting user, timestamp, and initial field values
- Validating, executing, posting, and reversing an allocation cycle each emit audit events recording the status transition and acting user
- Only users with appropriate permissions can create, validate, execute, post, or reverse allocation cycles

## Reference Links

- [SAP Cost Center Accounting: Assessment and Distribution](https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/ee3509643e954b3da2e0ebfa846c02e1/b867e2f9b57c4dc3b7ec7356aca3bb4e.html)
- [SAP Allocation Cycles in Controlling](https://help.sap.com/docs/SAP_ERP/29e50beaa37a447f8e4c13b0c5a15f32/42a07c62b9f343e0e10000000a11466f.html)
- [Oracle Fusion Cost Allocation Manager](https://docs.oracle.com/en/cloud/saas/financials/24d/oafcf/cost-allocation.html)
- [Odoo Analytic Accounting and Cost Distribution](https://www.odoo.com/documentation/19.0/applications/finance/accounting/reporting/analytic_accounting.html)
