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:
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:
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 integrationThe 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 | What Moves | When | Trade-off |
|---|---|---|---|
| A1 — Transfer the AuC | The open Asset under Construction, before capitalisation | At handover, prior to AIBU | Depreciation has never started; cleanest value basis; but an investment-measure AuC cannot be moved by a simple FI-AA transaction while still under the WBS — it must first be detached or settled |
| A2 — Capitalise then transfer | The completed fixed asset, after capitalisation in the central entity | After AIBU in the central entity | Depreciation may have begun in the central entity; the receiver takes over an asset with history; more transactions, more reconciliation |
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.
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:
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.ABZON (acquisition with automatic offsetting entry) or F-90 against the IC vendor — establishing new APC, useful life, and depreciation-area values.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 lifeThe 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).
| Dimension | Gross Method | Net Method |
|---|---|---|
| APC carried to receiver | Original historical APC | Net book value becomes new APC |
| Accumulated depreciation | Carried over to receiver | Reset — receiver starts clean |
| Remaining useful life | Continues original schedule | Re-assessed in receiver |
| P&L impact if transferred at NBV | None | None |
| P&L impact if transferred at a price | Gain/loss on the difference | Gain/loss on the difference |
| Consolidation cleanliness | Group sees original basis; simplest elimination | Requires care — reset basis can obscure group history |
| Best for | Affiliated entities keeping asset history intact | Handover where the receiver wants a fresh depreciation schedule |
The independent decision layered on top of method is price:
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.
| Element | Requirement | SAP / Governance Point |
|---|---|---|
| Arm’s-length basis | Transfer price defensible as what an unrelated party would pay | Transfer-pricing study before handover; documented valuation |
| Gain/loss recognition | Difference between price and NBV posts to P&L in the central entity | Transaction type on the retirement; gain/loss account determination (AO90) |
| Withholding tax | Some jurisdictions levy WHT on intercompany asset sales | WHT config on the IC customer/vendor master |
| VAT / GST | Cross-border asset transfer may attract indirect tax | Tax procedure on the IC billing document type |
| Permanent establishment | A pattern of central build-and-sell can raise PE questions | Legal/tax governance — informs whether transfer or a service model is correct |
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.
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:
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.
| Balance Sheet / P&L Line | Central Standalone | Segment Standalone | Group Consolidated |
|---|---|---|---|
| Fixed Asset | — (disposed at handover) | At transfer value | At original group cost basis |
| Gain on IC Transfer | Recognised (if priced) | — | Eliminated |
| IC Transfer AR | Raised | — | Eliminated |
| IC Transfer AP | — | Raised | Eliminated |
| Depreciation (on step-up) | — | Higher (on stepped-up base) | Excess reversed over life |
| Object | Transaction | Purpose |
|---|---|---|
| WBS settlement to AuC | CJ88 / CJB1 | Accumulates RRB and vendor cost to central AuC |
| AuC line-item settlement | AIAB | Distributes AuC to final asset line items |
| Capitalisation | AIBU | Posts AuC to a completed fixed asset (Variant A2) |
| Asset retirement / sale | ABAON / F-92 | Disposes the asset to the segment; recognises gain/loss if priced |
| Intercompany transfer (intra-instance) | ABT1N | Single-step cross-company transfer where same instance |
| Transfer variant / relationship type | SPRO FI-AA | Elects gross vs net method |
| Gain/loss account determination | AO90 | Maps transaction type to gain/loss and clearing GL |
| IC clearing account | FS00 | Trading partner mandatory for elimination |
| Trading partner | OX15 | Drives automatic IC elimination |
| Object | Transaction | Purpose |
|---|---|---|
| Asset acquisition | ABZON / F-90 | Establishes the asset in the segment with new APC per area |
| Asset master | AS01 | Company code = segment; profit centre, cost centre, useful life |
| Depreciation key per area | AFAMA | Method and life per depreciation area on the incoming asset |
| Account determination | AO90 | Asset class / transaction type to GL per area |
| Capitalisation date control | OAYB | Derives depreciation start in the segment |
| IC clearing / vendor | FS00 / XK01 | Receives the IC advice; trading partner mandatory |
| Object | Tool | Purpose |
|---|---|---|
| IC transfer AR/AP elimination | SAP Group Reporting | Nets the transfer receivable and payable |
| Unrealised profit elimination | SAP Group Reporting | Removes the intragroup gain on the asset |
| Excess depreciation reversal | SAP Group Reporting | Releases the eliminated profit over asset life |
| CapEx / asset movement report | BW/4HANA InfoProvider | Tracks the asset across both instances by trading partner |
| # | Risk | SAP Control | Process Control |
|---|---|---|---|
| 1 | Central entity holds AuC without genuine control — recognition challenged | Asset class and profit-centre validation in central instance | Accounting position paper on control before AuC is opened centrally |
| 2 | Investment-measure AuC cannot be transferred directly | Capitalise via AIBU first, then transfer the completed asset | Handover runbook enforces settle-capitalise-transfer sequence |
| 3 | Priced transfer inflates segment depreciable base | Transfer variant locked; VK11-style authorisation on the transfer price | Transfer-pricing study signed off before handover |
| 4 | Gain/loss posted incorrectly per depreciation area | Area-aware transaction types; AO90 per area | Asset accounting review of each area’s NBV pre-transfer |
| 5 | Cross-instance transfer values not reconciled | Trading-partner IC clearing; IDoc/CPI reconciliation report | Two-sided reconciliation before both books close |
| 6 | Unrealised profit not eliminated at group | Automatic IC elimination on trading-partner GL | Consolidation reconciliation before publish |
| 7 | Excess depreciation on step-up not reversed over life | Group Reporting recurring elimination task | Annual review that the reversal schedule matches asset life |
| 8 | Depreciation posts in central entity before handover | Align capitalisation and transfer dates to same period/day | Period-end calendar coordinates cap and transfer in one window |
| 9 | Tax area incorrectly recognises the step-up | Tax area excluded from step-up; permanent/temporary difference flagged | Tax team reviews area config at go-live and per transfer |
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