SAP S/4HANA Project System — Part 3: Centralised AuC with Intercompany Asset Transfer at Capitalisation

This document is Part 3 of the Project System series. Part 1 establishes the PS structure, Resource-Related Billing, and the cross-instance HR chargeback framework. Part 2 develops the funded CapEx scenario where the asset is acquired and operated in the segment from day one. This document addresses the structurally opposite pattern: the asset is built centrally and handed out at completion.

The two papers so far describe a world in which the asset capitalises in the entity that will operate it. RRB moves cost across the entity boundary via an SD invoice precisely so that the asset never has to move — the WBS, the AuC, and the final fixed asset all live in the operating entity.

This document addresses the case where that assumption is deliberately reversed:

• A central entity (Parent, or a shared development company) owns the project definition, the WBS hierarchy, and the Asset under Construction.
• The segments perform the work and bill it into the central WBS via the same Resource-Related Billing mechanism from Part 1 — the central entity is simply the recipient of those IC invoices rather than a segment.
• Costs accumulate on the central AuC through the construction phase.
• At completion, the finished asset is transferred out to the operating segment that will run it and carry it on its balance sheet.

The accumulation half of this pattern is already covered — it is Part 1’s RRB flow with the central entity playing the project-owner role. The novel capability is the final step: an intercompany asset transfer at capitalisation. Neither prior paper documents it, and Part 2’s central principle (“asset location follows control, not funding”) argues against ever letting the asset rest in a non-operating entity. This document defines the conditions under which the centralised pattern is nonetheless legitimate, and the SAP mechanics required to execute it cleanly.

The first question is not how to transfer the asset — it is whether the central entity is entitled to hold the AuC at all. Under IAS 16.7 and ASC 360, an asset is recognised by the entity that controls it and from which future economic benefits flow. That test is applied during construction, not only at completion.

This produces a hard fork:

• Central entity is a genuine developer / EPC principal. It directs construction, bears the construction risk, and holds the in-progress asset as its own until a defined handover. The AuC legitimately sits in the central entity, and the handover to the segment is a real disposal — a sale or a distribution — with all the transfer-pricing and gain/loss consequences that follow.
• Central entity is a funding or coordination conduit only. It does not control the asset in substance; the segment does. Parking the AuC centrally is not defensible, and the correct architecture is the Part 2 funded-CapEx model — budget or loan flows to the segment, and the asset is built in the segment from the first posting.

flowchart TD
    classDef structure fill:#fff3e0,stroke:#e65100
    classDef finance fill:#e3f2fd,stroke:#1565c0
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef reporting fill:#f3e5f5,stroke:#6a1b9a

    START["CapEx Programme<br>Central Entity Coordinates"]
    Q1{"Does the central entity<br>control the asset during<br>construction? (IAS 16.7 / ASC 360)"}
    Q2{"Is handover at a<br>transfer price or at<br>net book value?"}
    OPT_B["Use Part 2 Model<br>Asset built in segment<br>Budget / loan flows in<br>from central entity"]
    AUC_CENTRAL["Centralised AuC<br>legitimate in central entity"]
    NET["Net Method<br>Transfer at NBV<br>No IC gain/loss"]
    GROSS["Gross / Sale Method<br>Transfer at price<br>IC gain/loss + TP scrutiny"]

    START --> Q1
    Q1 -->|"No — conduit only"| OPT_B
    Q1 -->|"Yes — genuine developer"| AUC_CENTRAL
    AUC_CENTRAL --> Q2
    Q2 -->|"Net book value"| NET
    Q2 -->|"Transfer price"| GROSS

    class START,Q1,Q2 structure
    class AUC_CENTRAL,NET,GROSS finance
    class OPT_B integration

The decisive point: the centralised-AuC pattern is an architecture of last resort. It should be chosen because the legal and operational reality is that the central entity builds and then hands over — not because it is administratively convenient to pool CapEx centrally. If the only reason is pooling, Part 2 is the better answer and avoids the transfer entirely.

Once the central-hold is justified, there are two points at which the asset can cross the boundary.

Variant A1 is conceptually cleaner but runs into a specific SAP constraint: an AuC that is linked to a WBS as an investment measure is not freely transferable by ABT1N while the link is live. The supported path is to complete settlement of the WBS to the AuC (CJ88), then either detach the investment-measure link or capitalise (AIBU) and transfer the resulting asset — which collapses A1 into A2 in practice. A directly-capitalised AuC (not an investment measure) is more amenable to a direct transfer, but loses the WBS availability-control benefits.

The recommended pattern for most programmes is therefore A2 with immediate transfer: settle and capitalise in the central entity at period-end, transfer to the segment in the same period, so the asset carries at most one period of central-entity depreciation — and ideally set the capitalisation and transfer dates to the same day so no depreciation posts centrally at all.

The transaction depends entirely on whether the central entity and the segment share a system.

The native transaction is ABT1N — Intercompany Asset Transfer. It disposes the asset in the sending company code and acquires it in the receiving company code in a single posting, deriving both sides from the configured transfer variant.

• Do not use ABUMN — that is an intracompany transfer (within one company code) and will not cross the entity boundary.
• AIAB / AIBU settle only within a company code; they cannot be the vehicle for the cross-entity move. The asset transfer is an FI-AA transaction, not a CO settlement.

There is no native single-transaction intercompany transfer across instances. The move is modelled as a coordinated disposal in the source instance plus an acquisition in the target instance, linked through the intercompany AR/AP pair:

• Source (central) instance: retire the asset — ABAON (sale without customer) or, where a receivable is raised, an IC asset sale with revenue (F-92 pattern) — clearing the APC and accumulated depreciation and recognising any gain/loss.
• Target (segment) instance: acquire the asset — ABZON (acquisition with automatic offsetting entry) or F-90 against the IC vendor — establishing new APC, useful life, and depreciation-area values.
• Integration layer: the IC invoice / advice transmits via IDoc or CPI, exactly as the RRB IC invoice does in Part 1, and the two postings are reconciled through the trading-partner-tagged IC clearing accounts.

sequenceDiagram
    participant SEG as Segment (performs work)
    participant CEN as Central Entity Instance
    participant CPI as Integration Layer
    participant MFG as Operating Segment Instance
    participant GRP as Group Consolidation

    Note over SEG,CEN: CONSTRUCTION - RRB accumulation (Part 1)
    SEG->>SEG: CATS time / DP91 / VF01 IC invoice
    SEG->>CEN: IC invoice posts to central WBS
    CEN->>CEN: CJ88 WBS settlement to central AuC

    Note over CEN,MFG: HANDOVER - intercompany asset transfer
    CEN->>CEN: AIBU capitalise AuC to fixed asset
    CEN->>CEN: ABAON / F-92 retire asset (gain/loss if priced)
    CEN->>CPI: IC advice - IDoc / CPI iFlow
    CPI->>MFG: IC AP advice received
    MFG->>MFG: ABZON / F-90 acquire asset - new APC per area
    MFG->>MFG: Depreciation starts on cap date in segment

    Note over CEN,GRP: PERIOD END - consolidation
    CEN->>GRP: ACDOCA extract
    MFG->>GRP: ACDOCA extract
    GRP->>GRP: Eliminate IC transfer AR vs AP
    GRP->>GRP: Eliminate unrealised profit in asset
    GRP->>GRP: Reverse excess depreciation over life

The settle → capitalise → transfer sequence, with the intra- vs cross-instance fork, as a BPMN 2.0 process. The flow is maintained as an importable BPMN 2.0 template in the site’s process-template catalog.

<?xml version="1.0" encoding="UTF-8"?>
<bpmn:definitions xmlns:bpmn="http://www.omg.org/spec/BPMN/20100524/MODEL"
                  xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI"
                  xmlns:dc="http://www.omg.org/spec/DD/20100524/DC"
                  xmlns:di="http://www.omg.org/spec/DD/20100524/DI"
                  id="Defs_PsPart3Handover"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_CapitalisationHandover" name="Centralised AuC — Capitalisation and Handover" isExecutable="false">
    <bpmn:startEvent id="Start_HandoverApproved" name="Handover approved (control test passed)">
      <bpmn:outgoing>Flow_StartToSettle</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_SettleWbsToAuc" name="Settle WBS to central AuC (CJ88)">
      <bpmn:incoming>Flow_StartToSettle</bpmn:incoming>
      <bpmn:outgoing>Flow_SettleToCapitalise</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_CapitaliseAuc" name="Capitalise AuC to fixed asset (AIBU)">
      <bpmn:incoming>Flow_SettleToCapitalise</bpmn:incoming>
      <bpmn:outgoing>Flow_CapitaliseToGw</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_SameInstance" name="Central entity and segment on same instance?">
      <bpmn:incoming>Flow_CapitaliseToGw</bpmn:incoming>
      <bpmn:outgoing>Flow_GwToAbt1n</bpmn:outgoing>
      <bpmn:outgoing>Flow_GwToRetire</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_TransferAbt1n" name="Intercompany asset transfer (ABT1N)">
      <bpmn:incoming>Flow_GwToAbt1n</bpmn:incoming>
      <bpmn:outgoing>Flow_Abt1nToJoin</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_RetireCentral" name="Retire asset in central instance (ABAON / F-92)">
      <bpmn:incoming>Flow_GwToRetire</bpmn:incoming>
      <bpmn:outgoing>Flow_RetireToAcquire</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_AcquireSegment" name="Acquire asset in segment instance (ABZON / F-90)">
      <bpmn:incoming>Flow_RetireToAcquire</bpmn:incoming>
      <bpmn:outgoing>Flow_AcquireToJoin</bpmn:outgoing>
    </bpmn:task>
    <bpmn:exclusiveGateway id="Gw_Join" name="">
      <bpmn:incoming>Flow_Abt1nToJoin</bpmn:incoming>
      <bpmn:incoming>Flow_AcquireToJoin</bpmn:incoming>
      <bpmn:outgoing>Flow_JoinToReconcile</bpmn:outgoing>
    </bpmn:exclusiveGateway>
    <bpmn:task id="Task_ReconcileEliminate" name="Reconcile IC pair; eliminate at group (AR/AP, unrealised profit)">
      <bpmn:incoming>Flow_JoinToReconcile</bpmn:incoming>
      <bpmn:outgoing>Flow_ReconcileToEnd</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_AssetInSegment" name="Asset live on segment balance sheet">
      <bpmn:incoming>Flow_ReconcileToEnd</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_StartToSettle" sourceRef="Start_HandoverApproved" targetRef="Task_SettleWbsToAuc" />
    <bpmn:sequenceFlow id="Flow_SettleToCapitalise" sourceRef="Task_SettleWbsToAuc" targetRef="Task_CapitaliseAuc" />
    <bpmn:sequenceFlow id="Flow_CapitaliseToGw" sourceRef="Task_CapitaliseAuc" targetRef="Gw_SameInstance" />
    <bpmn:sequenceFlow id="Flow_GwToAbt1n" name="Same instance" sourceRef="Gw_SameInstance" targetRef="Task_TransferAbt1n" />
    <bpmn:sequenceFlow id="Flow_GwToRetire" name="Cross-instance" sourceRef="Gw_SameInstance" targetRef="Task_RetireCentral" />
    <bpmn:sequenceFlow id="Flow_RetireToAcquire" sourceRef="Task_RetireCentral" targetRef="Task_AcquireSegment" />
    <bpmn:sequenceFlow id="Flow_Abt1nToJoin" sourceRef="Task_TransferAbt1n" targetRef="Gw_Join" />
    <bpmn:sequenceFlow id="Flow_AcquireToJoin" sourceRef="Task_AcquireSegment" targetRef="Gw_Join" />
    <bpmn:sequenceFlow id="Flow_JoinToReconcile" sourceRef="Gw_Join" targetRef="Task_ReconcileEliminate" />
    <bpmn:sequenceFlow id="Flow_ReconcileToEnd" sourceRef="Task_ReconcileEliminate" targetRef="End_AssetInSegment" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_PsPart3Handover">
    <bpmndi:BPMNPlane id="Plane_PsPart3Handover" bpmnElement="Process_CapitalisationHandover">
      <bpmndi:BPMNShape id="Shape_Start" bpmnElement="Start_HandoverApproved">
        <dc:Bounds x="152" y="222" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="128" y="265" width="90" height="40" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Settle" bpmnElement="Task_SettleWbsToAuc">
        <dc:Bounds x="240" y="200" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Capitalise" bpmnElement="Task_CapitaliseAuc">
        <dc:Bounds x="410" y="200" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_GwSame" bpmnElement="Gw_SameInstance" isMarkerVisible="true">
        <dc:Bounds x="585" y="215" width="50" height="50" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="565" y="272" width="90" height="40" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Abt1n" bpmnElement="Task_TransferAbt1n">
        <dc:Bounds x="700" y="80" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Retire" bpmnElement="Task_RetireCentral">
        <dc:Bounds x="700" y="320" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Acquire" bpmnElement="Task_AcquireSegment">
        <dc:Bounds x="870" y="320" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_GwJoin" bpmnElement="Gw_Join" isMarkerVisible="true">
        <dc:Bounds x="1045" y="215" width="50" height="50" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Reconcile" bpmnElement="Task_ReconcileEliminate">
        <dc:Bounds x="1150" y="200" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End" bpmnElement="End_AssetInSegment">
        <dc:Bounds x="1322" y="222" width="36" height="36" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="1298" y="265" width="90" height="27" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_StartToSettle" bpmnElement="Flow_StartToSettle">
        <di:waypoint x="188" y="240" />
        <di:waypoint x="240" y="240" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_SettleToCapitalise" bpmnElement="Flow_SettleToCapitalise">
        <di:waypoint x="360" y="240" />
        <di:waypoint x="410" y="240" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_CapitaliseToGw" bpmnElement="Flow_CapitaliseToGw">
        <di:waypoint x="530" y="240" />
        <di:waypoint x="585" y="240" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_GwToAbt1n" bpmnElement="Flow_GwToAbt1n">
        <di:waypoint x="610" y="215" />
        <di:waypoint x="610" y="120" />
        <di:waypoint x="700" y="120" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="615" y="150" width="75" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_GwToRetire" bpmnElement="Flow_GwToRetire">
        <di:waypoint x="610" y="265" />
        <di:waypoint x="610" y="360" />
        <di:waypoint x="700" y="360" />
        <bpmndi:BPMNLabel>
          <dc:Bounds x="615" y="330" width="75" height="14" />
        </bpmndi:BPMNLabel>
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_RetireToAcquire" bpmnElement="Flow_RetireToAcquire">
        <di:waypoint x="820" y="360" />
        <di:waypoint x="870" y="360" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Abt1nToJoin" bpmnElement="Flow_Abt1nToJoin">
        <di:waypoint x="820" y="120" />
        <di:waypoint x="1070" y="120" />
        <di:waypoint x="1070" y="215" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_AcquireToJoin" bpmnElement="Flow_AcquireToJoin">
        <di:waypoint x="990" y="360" />
        <di:waypoint x="1070" y="360" />
        <di:waypoint x="1070" y="265" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_JoinToReconcile" bpmnElement="Flow_JoinToReconcile">
        <di:waypoint x="1095" y="240" />
        <di:waypoint x="1150" y="240" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_ReconcileToEnd" bpmnElement="Flow_ReconcileToEnd">
        <di:waypoint x="1270" y="240" />
        <di:waypoint x="1322" y="240" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

ABT1N and its cross-instance equivalent both require an election between two value-transfer methods, controlled by the transfer variant and its relationship type (configured under FI-AA → Intercompany Asset Transfers → Define Transfer Variants).

The independent decision layered on top of method is price:

• Transfer at net book value — no gain or loss, no transfer-pricing exposure, no unrealised profit to eliminate at group. This is the default recommendation for a genuine handover between affiliates.
• Transfer at a price (cost-plus, or arm’s-length market value) — recognises a gain in the central entity, gives the segment a stepped-up depreciable base, and pulls the transfer squarely into transfer-pricing scrutiny in every jurisdiction the asset crosses. It also creates unrealised intercompany profit that consolidation must eliminate and then release over the asset’s life.

If the handover is priced above net book value, the price is a transfer-pricing instrument in exactly the way the VK11 IC labour rate is in Part 2 — and it is arguably higher-risk, because it sets the depreciable base of a long-lived asset rather than a period cost.

The cleaner the design, the more it tends toward net-method, NBV transfer — which sidesteps all of the above at the cost of the central entity recognising no margin on the build. Whether the central entity should earn a margin is a business-model question that must be answered before the FI-AA configuration is touched.

The transfer must reproduce the asset correctly across every depreciation area in the receiver — and cross-instance, those areas must be re-established from scratch.

• Each area (Local GAAP 01, IFRS 15, Tax 30) may carry a different net book value at handover, because depreciation methods and any borrowing-cost capitalisation (IAS 23, per Part 2) differ by area.
• A priced transfer can produce a different gain/loss per area, because each area’s NBV differs. The retirement and acquisition postings must be area-aware.
• The tax area frequently cannot follow the accounting treatment — a step-up recognised for IFRS may not be recognised for tax, leaving a permanent or temporary difference the tax team must track.
• Cross-instance, the receiver’s AFAMA depreciation keys, useful lives, and AO90 account determination must be configured to accept the incoming values per area — this is where cross-instance transfers most often break.

This is the single largest reason to prefer an NBV transfer. When an asset is sold intragroup above its carrying amount, the gain is unrealised from the group’s perspective — the group still holds the same asset it always did, at the same underlying cost. Consolidation must:

1. Eliminate the intercompany AR/AP raised on the transfer (trading-partner-driven, as with every other IC pair in the series).
2. Eliminate the unrealised gain recognised in the central entity, restoring the asset to its original group carrying amount.
3. Reverse the excess depreciation the segment posts on the stepped-up basis — progressively, over the asset’s remaining life — which is how the eliminated profit is realised at group level as the asset is used.

Step 3 is a multi-year obligation, not a one-period entry. It is the fixed-asset analogue of unrealised-profit-in-inventory elimination, spread across the depreciation schedule, and it is precisely the “consolidation noise” the RRB architecture in Part 1 was designed to avoid. An NBV transfer eliminates steps 2 and 3 entirely — there is no unrealised profit and no excess depreciation — leaving only the routine AR/AP elimination.

Five decisions govern this pattern. As with the funded-CapEx scenario, none can be deferred to build.

1. Prove control before centralising the AuC. The centralised pattern is only legitimate when the central entity genuinely controls the asset during construction. If it is a funding or coordination conduit, use the Part 2 model and never let the asset touch the central books. This is an accounting decision that gates the entire architecture — resolve it in a signed position paper, not in configuration.

2. Transfer at net book value unless there is a business reason to earn a margin. An NBV transfer eliminates gain/loss, transfer-pricing exposure, and — decisively — the multi-year unrealised-profit and excess-depreciation elimination at group. A priced transfer is defensible only where the central entity is a genuine developer entitled to a construction margin, and even then it must rest on a transfer-pricing study completed before handover.

3. Capitalise then transfer in a single period (Variant A2). An investment-measure AuC is not cleanly transferable while linked to the WBS. Settle (CJ88), capitalise (AIBU), and transfer within the same period — aligning capitalisation and transfer dates so no depreciation posts in the central entity — is the pattern with the fewest moving parts and the least reconciliation.

4. Model the cross-instance transfer as coordinated disposal-plus-acquisition, reconciled on the trading partner. There is no native single transaction across instances. Treat it with the same rigour as the RRB IC invoice — IDoc/CPI transmission, trading-partner-tagged IC clearing, and a two-sided reconciliation report that must clear before either instance closes.

5. Own the consolidation obligation for the asset’s whole life. If any transfer is priced, the unrealised profit and the excess depreciation on the step-up must be eliminated every period until the asset is fully depreciated or retired. Build the recurring Group Reporting task at go-live and review annually that its schedule matches the asset’s life — this is the obligation that makes NBV transfers so much cheaper to live with.

The two prior papers make a deliberate architectural choice: move cost across the entity boundary, never the asset. Resource-Related Billing exists so that the AuC and the fixed asset capitalise directly in the operating entity, with no FI-AA transfer, no gain/loss, and no unrealised-profit elimination.

The centralised-AuC pattern reverses that choice, and every complication it introduces — the control test, the transfer-pricing exposure, the per-area gain/loss, the multi-year consolidation reversal — flows from re-adding the asset movement that RRB was structured to avoid. It is the right architecture only when the legal and operational reality is genuinely build centrally, hand over at completion. Where the motivation is merely to pool CapEx under a central sponsor, the funded-CapEx model of Part 2 delivers the same governance through the IM programme and the intercompany loan, keeps the asset in the operating segment throughout, and leaves nothing to eliminate but a clean AR/AP pair.

Related: Part 1 — Architecture, RRB, and Cross-Instance CapEx · Part 2 — Funded CapEx, Parent Financing, and Multi-GAAP Asset Settlement