SAP S/4HANA Project System, Part 1: Architecture, Resource-Related Billing, and Cross-Instance CapEx

Part 1 of a three-part series. This document establishes the PS structural architecture, Resource-Related Billing (RRB), and the cross-instance HR chargeback framework. Part 2 develops the funded CapEx scenario — where the Parent entity receives external financing but the asset is acquired and operated by MFG — and shows how funding, RRB labour chargeback, and vendor acquisition converge on the same WBS infrastructure. Part 3 addresses the structurally opposite pattern — a centralised AuC built in a central entity and handed out to the operating segment via intercompany asset transfer at capitalisation.

Executive Summary

Capital expenditure programs in multi-entity enterprises routinely involve employees from one legal entity performing work that benefits another — building an asset that sits on a different company’s balance sheet, under a different instance of SAP. The conventional response to this problem is organisational: move the employees, replicate the HR master data, or create shadow headcount in the receiving entity. None of that is necessary.

SAP S/4HANA Project System, combined with Resource-Related Billing (RRB) and the Cross-Application Time Sheet (CATS) framework, provides a complete native solution. Employees stay in their home entity. Their confirmed hours flow through CATS into Controlling, where the Dynamic Item Processor (DIP Profile) converts actual cost line items into a structured intercompany SD invoice. That invoice crosses the entity boundary — via IDoc or SAP Integration Suite — and lands as an Accounts Payable posting against the project-owning entity’s WBS element. The WBS element settles to an Asset under Construction. The AuC capitalises to a fixed asset. The intercompany AR and AP pair is eliminated at group consolidation. The employee’s HR record, payroll, and organisational assignment never move.

External time systems — Kronos/UKG, Workday Time, SAP Fieldglass — slot into this architecture through the CATS staging layer and a CPI integration layer that handles routing, labour code mapping, and personnel number resolution. The entity boundary is invisible to those systems; it is resolved entirely in middleware.

This whitepaper documents the complete architectural flow: PS structural components and master data, the CapEx WBS-to-AuC settlement path, intercompany counterparty configuration, RRB and DIP profile mechanics, CATS and external time system integration, the cross-instance proxy WBS pattern, period-end closing sequence, and implementation guidance.

Context

Large capital programs at multi-entity enterprises — infrastructure builds, technology platform deployments, manufacturing facility expansions — share a structural problem: the entity that owns the asset being built is rarely the entity whose workforce builds it. Shared services centres, engineering centres of excellence, and regional delivery entities do the work. The project-owning holding company or operating entity capitalises the result.

We encountered this problem directly in the context of a Fortune 100 technology company operating a multi-instance SAP landscape, where capital expenditure programs span legal entities across jurisdictions, each on its own S/4HANA instance with its own HR organisation, controlling area, and fixed asset register. The question was specific: can employees in Entity A charge hours to a project owned by Entity B, without being organisationally reassigned, without HR master data replication, and with a legally clean intercompany trail?

The answer SAP Project System provides is yes — but the path through configuration is not trivial. This whitepaper traces that path completely.

Analysis

The Core Structural Layer: Project Definition to Network Activity

Every PS deployment begins with the project hierarchy. The Project Definition (PROJ) is the header object — it carries the controlling area, company code, and project profile. Below it sits the WBS (Work Breakdown Structure) hierarchy, stored in PRPS (element master) and PRHI (hierarchy relationships). WBS elements are the primary cost collection objects for CapEx: every cost incurred on a project — procurement, labour, services, overhead — is accumulated on a WBS element before settlement downstream.

Networks and Activities (AUFK / AFKO for headers, AFVC / AFVV for activity detail) sit alongside the WBS hierarchy and handle scheduling, capacity planning, and work confirmation. Activities carry Work Centres (CR01), which link back to HR organisational units and drive capacity availability. Milestones (MLST) hang off activities and serve as billing triggers in customer-funded project scenarios. Material Components (RESB) capture dependent procurement requirements raised from network activities.

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

    PD["Project Definition<br>(PROJ)"]
    WBS["WBS Elements<br>(PRPS / PRHI)"]
    NW["Networks and Activities<br>(AUFK / AFKO / AFVC)"]
    MS["Milestones (MLST)"]
    MC["Material Components (RESB)"]

    PD --> WBS
    WBS --> NW
    NW --> MS
    NW --> MC

    subgraph FIN["Financial Objects"]
        AUC["Asset Under Construction<br>(FI-AA AuC)"]
        IO["Internal Orders (AUFK)"]
        CO["CO Settlement Rules"]
    end

    subgraph EXEC["Execution Objects"]
        PM["PM Orders (Subnetworks)"]
        PO["Purchase Requisitions and POs<br>(MM Integration)"]
        SO["Sales Orders and Billing<br>(SD Integration)"]
    end

    WBS --> AUC
    WBS --> IO
    WBS --> CO
    NW --> PM
    WBS --> PO
    WBS --> SO

    class PD,WBS,NW,MS,MC structure
    class AUC,IO,CO finance
    class PM,PO,SO integration

The master data landscape behind this hierarchy is the foundation for data migration, reporting, and API integration:

Object	Primary Tables	Description
Project Definition	`PROJ`	Top-level project header
WBS Elements	`PRPS`, `PRHI`	Master data and hierarchy
WBS Dates	`PRTE`	Scheduled and actual dates
Networks / Orders	`AUFK`, `AFKO`	Network headers and order data
Network Activities	`AFVC`, `AFVU`, `AFVV`	Activity detail and user fields
Material Components	`RESB`	Dependent requirements
Milestones	`MLST`	Activity-level milestones
Primary Cost Totals	`COSP`	Primary cost totals records
Secondary Cost Totals	`COSS`	Internal allocation totals
Actual Cost Line Items	`COEP`	Line-item actuals (legacy path)
Commitments	`COOI`	Open PO and PR commitments
Universal Journal	`ACDOCA`	S/4HANA single source of truth
Project Cost Roll-Up	`RPSCO`	Costs and revenues aggregated
Budget	`BPGE`, `BPJA`	Overall and fiscal-year budget

In S/4HANA, ACDOCA is the authoritative source. COEP remains populated for compatibility but the RRB engine should be pointed at the Universal Journal source in any S/4HANA 2022+ deployment — more on this in the RRB section.

The CapEx Financial Flow: WBS to Fixed Asset

The CapEx flow is the reason PS exists in most enterprise deployments. WBS elements function as temporary cost collectors during the construction or development phase of an asset. Costs accumulate from procurement, service confirmations, and internal labour. At period end, those costs settle to an Asset under Construction (AuC) in FI-AA. At project completion or a defined capitalisation milestone, the AuC is distributed to one or more final fixed assets where depreciation begins.

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

    PR["Purchase Requisition<br>raised on WBS"]
    PO["Purchase Order (MM)"]
    GR["Goods Receipt<br>Cost hits WBS"]
    IV["Invoice Verification (MIRO)"]
    WBS["WBS Element<br>CapEx Cost Collector"]
    SET["Periodic Settlement<br>(CJ88 / CJB1)"]
    AUC["Asset Under Construction<br>(FI-AA)"]
    CAP["Capitalisation Event<br>(AIAB / AIBU)"]
    FA["Fixed Asset<br>Depreciation begins"]
    ACDOCA["ACDOCA Universal Journal"]

    PR --> PO --> GR --> WBS
    IV --> WBS
    WBS --> SET --> AUC --> CAP --> FA
    WBS --> ACDOCA
    AUC --> ACDOCA
    FA --> ACDOCA

    class PR,PO,GR,IV integration
    class WBS structure
    class SET,AUC,CAP,FA,ACDOCA finance

The key configuration objects governing this flow:

Configuration Area	Transaction	Purpose
Project Profile	`OPSA` / `CJ20N`	Controls planning, budgeting, settlement behaviour
Settlement Profile	`OKO7`	Defines valid settlement receivers including AuC
AuC Asset Class	`OAOA`	Separate asset class for AuC; links to depreciation areas
Investment Profile	`IM01`	Ties WBS to Investment Management appropriation requests
Budget Profile	`OPS9`	Availability control tolerances and update modes
WBS Settlement to AuC	`CJ88` / `CJB1`	Individual and collective periodic settlement
AuC Line Item Settlement	`AIAB`	Distributes AuC costs to final asset line items
AuC Capitalisation	`AIBU`	Posts capitalisation from AuC to fixed asset
Depreciation Run	`AFAB`	Calculates and posts periodic depreciation

Intercompany CapEx: Cross-Entity Project Execution

When a leading company code owns the project and WBS hierarchy but a partner company code performs the work, intercompany flows are required. The executing entity incurs costs — labour, procurement, services — and must charge them to the project-owning entity in a legally clean way that supports both entity-level P&L reporting and group consolidation elimination.

flowchart TD
    classDef source fill:#fff3e0,stroke:#e65100
    classDef integration fill:#e8f5e9,stroke:#2e7d32
    classDef target fill:#e3f2fd,stroke:#1565c0

    subgraph CC1["Company Code A — Project Owner"]
        WBS_A["WBS Element<br>CapEx Cost Collector"]
        AUC_A["AuC — Final Asset<br>Company A Books"]
    end

    subgraph CC2["Company Code B — Executing Entity"]
        NW_B["Network Activity<br>Labour and Services"]
        PO_B["Purchase Order<br>Company B Procurement"]
        IC_AR["Intercompany AR<br>SD Billing"]
    end

    subgraph IC["Intercompany Settlement Layer"]
        IC_AP["Intercompany AP<br>Company A"]
        IC_ELIM["Group Elimination<br>Consolidation"]
    end

    NW_B --> IC_AR
    PO_B --> NW_B
    IC_AR -->|"IC Invoice"| IC_AP
    IC_AP --> WBS_A
    WBS_A --> AUC_A
    IC_AR --> IC_ELIM
    IC_AP --> IC_ELIM

    class WBS_A,AUC_A target
    class NW_B,PO_B,IC_AR source
    class IC_AP,IC_ELIM integration

The counterparty configuration objects required:

Configuration Object	Transaction	Purpose
Trading Partner	`OX15`	Assigned to company code; drives group elimination
IC Customer	`XD01`	Project-owning entity as customer in executing entity
IC Vendor	`XK01`	Executing entity as vendor in project-owning entity
IC Sales Organisation	`OVX5`	Executing entity’s sales org for IC transactions
IC Order Type	`VOV8`	Sales document type for IC billing
IC Billing Type	`VOFA`	Billing document type for IC invoices
IC Pricing Procedure	`OVKK`	Condition schema for IC labour rate pricing
IC Condition Record	`VK11`	Rate per activity type or service material per IC customer
Output Type	`NACE`	Triggers IDoc INVOIC02 output on IC invoice save
Profit Centre on WBS	`CJ20N`	WBS linked to entity profit centre for segment reporting
Document Splitting	SPRO → GL	Ensures company code and segment on every posting line

Resource-Related Billing is the mechanism by which actual costs incurred on a project are automatically converted into billable line items on an SD sales document — without manual re-entry. It is the bridge between CO actuals and SD invoicing, and it is the answer to the cross-entity labour chargeback problem.

The engine is the Dynamic Item Processor (DIP Profile), configured via transaction ODP1. The DIP Profile reads cost line items from the project in ACDOCA (S/4HANA 2022+, preferred) or COEP (legacy path), groups them into dynamic items according to defined characteristics, determines the SD billing material and price, and feeds the result into an SD billing request via DP91. That billing request becomes an IC invoice via VF01 / VF04.

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

    subgraph HOME["Home Entity — Executing Company Code"]
        EMP["Employee<br>HR Master PA / OM"]
        CA["Activity Type<br>Cost Centre / Activity"]
        TIME["Time Confirmation<br>CATS / External System"]
        COEP["Cost Line Items<br>ACDOCA / COEP"]
        WBS_E["WBS Element or Proxy<br>Executing Entity"]
    end

    subgraph RRB_ENG["RRB Engine"]
        DIP["DIP Profile<br>Dynamic Item Processor"]
        DP90["DP90 Billing Request Creation"]
        DP91["DP91 Billing Document Update"]
    end

    subgraph IC_BILL["Intercompany Billing Layer"]
        SD_QUO["SD Quotation or Order<br>IC Sales Document"]
        IC_INV["Intercompany Invoice<br>SD Billing Document"]
        IC_AR["IC Accounts Receivable<br>Executing Entity"]
        IC_AP["IC Accounts Payable<br>Project-Owning Entity"]
    end

    subgraph OWN["Project-Owning Entity"]
        WBS_O["WBS Element<br>CapEx Cost Collector"]
        AUC["Asset Under Construction"]
    end

    EMP --> TIME
    CA --> TIME
    TIME --> COEP
    COEP --> WBS_E
    WBS_E --> DIP
    DIP --> DP90
    DP90 --> SD_QUO
    SD_QUO --> DP91
    DP91 --> IC_INV
    IC_INV --> IC_AR
    IC_INV --> IC_AP
    IC_AP --> WBS_O
    WBS_O --> AUC

    class EMP,CA,TIME,COEP,WBS_E structure
    class DIP,DP90,DP91 finance
    class SD_QUO,IC_INV,IC_AR,IC_AP integration
    class WBS_O,AUC reporting

The DIP Profile components and their configuration for a labour hours-based IC chargeback:

DIP Profile Component	Configuration for Labour Chargeback
Source	ACDOCA — Actuals Cost from Universal Journal (S/4HANA 2022+)
Characteristics	Cost element + activity type + sender cost centre
Quantity / Amount	Hours (quantity-based, not value-based)
Material Determination	IC service material per activity type (e.g. `IC-LABOUR-ENGR`)
Pricing	VK11 IC condition record — fixed rate per hour or cost pass-through
Update	Mark cost lines as billed after DP91 run — prevents double billing

The SD invoice line produced reads: X hours of Engineering Labour at $Y per hour = $Z — not a lump sum. This granularity is what the project-owning entity needs to correctly classify and capitalise costs to the right asset component.

S/4HANA 2022 RRB Source — Important

The S/4HANA 2022 Simplification List explicitly introduces “Actuals Cost from Universal Journal” as the preferred DIP profile source, superseding the legacy COEP-based path. The legacy path remains in compatibility scope but receives no further innovation. Any new deployment on S/4HANA 2022 or later must configure the DIP profile source accordingly. SAP Note 2677564 covers the performance optimization for high-volume RRB scenarios on either source path.

HR’s Role — What Stays in the Home Entity

This is architecturally decisive. The answer is unambiguous: employees do not need to be moved, replicated, or organisationally reassigned to the project-owning entity. The RRB architecture is specifically designed to avoid this.

What HR Must Supply — Home Entity Only

HR Object	Table / Infotype	What RRB Uses It For
Personnel Number	`PA0001` Org Assignment	Links CATS time entry to cost centre and company code
Cost Centre Assignment	`PA0001` Cost Centre field	Primary CO object receiving time costs
Activity Type	`KL01` / CSSL	Labour activity type drives the cost rate per hour
Work Centre	`CR01` linked to HR position	Network activity assignment; determines capacity
HR-CO Integration	`CATSCO` transfer program	Transfers confirmed hours from CATS to CO actual postings
Employee Grouping	SPRO → CATS	Maps employee groupings to default activity types
Plan Activity Rate	`KP26`	Planned price per activity type per cost centre
Actual Rate Calculation	`KSII`	Actual activity price calculated at period end

What HR Does Not Need to Supply

Concern	Answer
Employee personnel number in project-owning entity	Not required. Employee stays under home company code.
Org assignment to project-owning entity	Not required. Profit centre and segment derivation happen at WBS level.
Work Centre replica in project-owning system	Not required in cross-instance model. Network activities live in the executing entity’s system.
HR org unit replication cross-instance	Not required unless central Fiori capacity planning apps are in scope.
Payroll integration to project-owning entity	Never crosses entity. Payroll runs entirely in the home entity.

Company B — the project-owning entity — never sees the employee at all. It sees an IC vendor invoice, with line items broken down by service material, quantity in hours, and rate. Those costs land on the WBS element, settle to AuC, and capitalise to the fixed asset.

CATS: The Integration Bridge Between HR Time and PS Costs

CATS (Cross-Application Time Sheet) is not a workforce management application in the sense that Kronos or Workday Time is. It is an SAP-native time entry and transfer framework — a posting layer. Its job is to accept time records (from a native UI or an inbound interface), stage them in CATSDB, and transfer them on demand to CO, PS, PM, MM, or HR Time Management via dedicated batch transfer programs.

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

    subgraph EXTERNAL["External Time Systems"]
        KRONOS["Kronos / UKG<br>Workforce Central"]
        WORKDAY["Workday Time Tracking"]
        FIELDGLASS["SAP Fieldglass<br>Contingent Labour"]
        CUSTOM["Custom Web or Mobile<br>Time Entry App"]
    end

    subgraph CATS_LAYER["SAP CATS — Staging and Transfer Layer"]
        BAPI_TIME["BAPI_CATS_CREATE<br>Inbound API"]
        CATSDB["CATSDB<br>Time Sheet Staging Table"]
        CAT2["CAT2 Native SAP<br>Time Entry UI"]
        APPROVE["Approval Workflow<br>Optional"]
        CATSCO["CATSCO to CO<br>Activity Confirmation"]
        CATSPM["CATSPM to PM<br>Order Confirmation"]
        CATSMM["CATSMM to MM<br>Service Entry Sheet"]
        RPTEXTPT["RPTEXTPT to HR<br>Time Evaluation"]
    end

    subgraph DOWNSTREAM["CO and PS Downstream"]
        COEP["ACDOCA<br>Actual Cost Posting"]
        WBS["WBS Element<br>Cost Accumulation"]
        NW["Network Activity<br>Confirmation"]
    end

    KRONOS -->|"BAPI / IDoc / CPI iFlow"| BAPI_TIME
    WORKDAY -->|"REST API via CPI iFlow"| BAPI_TIME
    FIELDGLASS -->|"SAP Standard iFlow"| BAPI_TIME
    CUSTOM -->|"BAPI or OData"| BAPI_TIME
    CAT2 --> CATSDB
    BAPI_TIME --> CATSDB
    CATSDB --> APPROVE
    APPROVE --> CATSCO
    APPROVE --> CATSPM
    APPROVE --> CATSMM
    APPROVE --> RPTEXTPT
    CATSCO --> COEP
    CATSCO --> WBS
    CATSPM --> NW

    class KRONOS,WORKDAY,FIELDGLASS,CUSTOM integration
    class BAPI_TIME,CATSDB,CAT2,APPROVE structure
    class CATSCO,CATSPM,CATSMM,RPTEXTPT finance
    class COEP,WBS,NW reporting

The standard inbound API is BAPI_CATS_CREATE. The fields that matter for cross-entity PS posting:

Field	Content	Source in External System
`PERNR`	Personnel number	Employee ID resolved via mapping layer
`WORKDATE`	Date of work	Time entry date
`CATSHOURS`	Hours worked	Confirmed hours from external system
`RPROJ` / `RPRZNR`	WBS element	Proxy WBS ID (cross-instance) or real WBS (single-instance)
`RAUFNR`	Network or order number	PS network activity reference
`LSTAR`	Activity type	Labour category code
`SKOSTL`	Sender cost centre	Employee’s home cost centre
`BUDAT`	Posting date	Accounting period for CO posting

CATS Configuration for Cross-Entity Time Posting

Configuration Object	Transaction	Notes
CATS Profile	`CAC1`	Controls field visibility; WBS and network receiver field must be enabled
Data Entry Profile	`CAC2`	Assigned per employee group; determines transfer method
Receiver Type	CATS Profile	Set to `PSP` for WBS or Network Activity
Cross-CC Posting	CO area configuration	CO area must span both company codes or cross-CC posting must be activated
Activity Type Default	Employee Grouping → Activity Type	Ensures correct labour rate without manual selection
Approval Workflow	SPRO → CATS → Approval	Recommended for CapEx audit trail

External Time Systems: Kronos, Workday, and Fieldglass

Each major time system connects to CATS via a different integration pattern, but the result in CATSDB is identical regardless of source.

Kronos / UKG

Kronos does not natively understand SAP WBS elements or activity types. The integration bridge:

Step	What Happens
Labour Code Mapping	Kronos labour and pay codes mapped to SAP activity types in CPI value mapping
Cost Centre Mapping	Kronos department or org level codes mapped to SAP cost centres
Project Code Field	Kronos custom work order or project field carries the SAP WBS element ID
Extract	Kronos produces a scheduled time export — flat file, REST API, or database extract
Transform	CPI iFlow transforms Kronos payload into `BAPI_CATS_CREATE` input structure
Load	BAPI call writes records to `CATSDB`
Transfer	`CATSCO` batch job runs nightly or at period-end to post actuals to CO and PS

Workday Time

Workday Time is architecturally cleaner because SAP delivers a standard Workday–SAP integration package via SAP Integration Suite:

SAP Standard Package	Direction	What It Does
Workday Employee Time to SAP CATS	Workday → SAP	Transfers approved time blocks to CATSDB via `BAPI_CATS_CREATE`
SAP Cost Centre and WBS to Workday	SAP → Workday	Publishes WBS element IDs to Workday so employees can select them during time entry

The second iFlow is critical — it is what allows an employee in Workday Time to see and select the project-owning entity’s WBS element during time entry, even though they are employed under the executing entity.

SAP Fieldglass (Contractor Labour)

Contractors have no personnel number — the CATS path does not apply. Fieldglass manages the contractor’s timesheet and approval. Upon approval, Fieldglass generates a Service Entry Sheet in SAP MM, which posts to the WBS element via account assignment category Q. That cost lands in ACDOCA on the WBS and is picked up by the DIP profile alongside employee labour costs. A single IC invoice can therefore aggregate both employee hours (via CATS) and contractor services (via Fieldglass SES) — the DIP profile is the consolidation point.

Can External Time Systems Post to Multiple SAP Instances?

Yes — and this is purely a middleware configuration question. An external time system produces a time record. The CPI iFlow determines which SAP instance to route it to, based on a discriminator field in the record:

Discriminator	Source in External System	Maps To
Company Code	Department or org level	SAP company code → instance routing table
Project Code	Custom work order or project field	WBS element prefix determines target instance
Legal Entity	Workday legal entity or Kronos location	SAP company code → instance

The routing table is maintained as a CPI value mapping — a simple lookup that says “Company Code 1000 → Instance A endpoint; Company Code 2000 → Instance B endpoint.” Kronos and Workday need no configuration changes to support multi-instance posting.

The Cross-Instance Architecture: Proxy WBS Pattern

When the executing entity and the project-owning entity are on separate S/4HANA instances, CATS cannot directly reference a WBS element from the other instance. The recommended pattern is the Proxy WBS:

A mirror WBS element is created in the executing entity’s instance, using the project-owning entity’s WBS reference number as the identifier
Employees confirm time against the proxy WBS
Costs accumulate in the executing entity’s ACDOCA
DIP profile reads those costs and generates an IC invoice
The IC invoice transmits cross-instance and posts to the real WBS in the project-owning entity

WBS master data synchronisation — creation of proxy WBS elements when real WBS elements are created in the project-owning instance — is automated via the API_PROJECT_V3 OData service, triggered by a CPI iFlow.

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

    subgraph INST_A["S/4HANA Instance A — Executing Entity"]
        WBS_PROXY["Proxy WBS Element<br>mirrors project-owning entity ref"]
        CATS_A["CATS Entry<br>hours against proxy WBS"]
        COEP_A["ACDOCA Actuals<br>Instance A"]
        DIP_A["DIP Profile DP91"]
        INV_A["IC Invoice VF01"]
    end

    subgraph MIDDLEWARE["Integration Middleware CPI"]
        SYNC["Project Master Sync<br>API_PROJECT_V3"]
        BILL["Invoice Transmission<br>IDoc INVOIC02"]
    end

    subgraph INST_B["S/4HANA Instance B — Project Owner"]
        WBS_B["WBS Element<br>Real CapEx Collector"]
        MIRO_B["MIRO IC AP Invoice"]
        AUC_B["AuC to Fixed Asset"]
    end

    CATS_A --> WBS_PROXY
    WBS_PROXY --> COEP_A
    COEP_A --> DIP_A
    DIP_A --> INV_A
    INV_A --> BILL
    WBS_B --> SYNC
    SYNC -->|"Proxy WBS creation"| WBS_PROXY
    BILL --> MIRO_B
    MIRO_B --> WBS_B
    WBS_B --> AUC_B

    class WBS_PROXY,CATS_A,COEP_A structure
    class DIP_A,INV_A finance
    class SYNC,BILL integration
    class WBS_B,MIRO_B,AUC_B reporting

CO Area: The Most Critical Architectural Decision

Whether resources can post time across entities without a cross-instance call depends on the CO area configuration:

Scenario	CO Area Setup	Implication
Same S/4HANA instance, different company codes	Single CO area spanning both company codes (preferred)	CATS can post directly to either entity’s WBS; RRB and IC billing still required for legal entity reporting but CO consolidation is seamless
Separate S/4HANA instances	Separate CO areas per instance (required)	Proxy WBS pattern is mandatory; CATS posts to proxy in Instance A; IC invoice carries cost to Instance B

Personnel Number Resolution

BAPI_CATS_CREATE requires a SAP personnel number (PERNR), which is instance-specific. External systems use their own employee IDs. The mapping options:

Option	Mechanism	Best For
Global Employee ID infotype	`PA0709` or custom infotype stores external ID; CPI resolves at runtime	SAP HCM as HR system of record
SuccessFactors Employee Central	EC maintains canonical employee ID; CPI queries EC API	SuccessFactors deployments
CPI value mapping table	Static mapping: external ID → PERNR per instance	Limited employee population; pragmatic approach
SAP standard Workday iFlow	PERNR lookup handled natively in SAP-delivered package	Greenfield Workday + SAP HCM

Personnel number resolution is only needed for the executing entity’s instance — Company B never sees the personnel number. The IC invoice abstracts the employee completely into hours, activity type, and service material.

End-to-End Flow: Time Entry to Fixed Asset

The complete cross-instance flow, step by step:

sequenceDiagram
    participant EMP as "Employee (Company A)"
    participant CATS as "CATS / CAT2 or External System"
    participant CO_A as "CO / ACDOCA Instance A"
    participant RRB as "DIP Profile / DP91"
    participant SD_A as "SD Billing VF01"
    participant INT as "Integration Layer CPI / IDoc"
    participant MM_B as "MIRO Instance B"
    participant PS_B as "WBS / CJ88 Instance B"
    participant AA_B as "FI-AA AuC Instance B"

    EMP->>CATS: Enter hours against WBS reference
    CATS->>CO_A: CATSCO transfer — activity confirmation
    CO_A->>CO_A: Actual cost posted to ACDOCA
    CO_A->>RRB: DIP reads ACDOCA cost line items
    RRB->>SD_A: Billing request created via DP91
    SD_A->>SD_A: IC Invoice generated VF01
    SD_A->>INT: IDoc INVOIC02 or CPI iFlow
    INT->>MM_B: IC AP invoice posted MIRO
    MM_B->>PS_B: Cost hits WBS element
    PS_B->>AA_B: Periodic settlement CJ88 to AuC
    AA_B->>AA_B: Capitalisation AIBU to Fixed Asset

Period-End Closing Sequence

The period-end sequence is a strict dependency chain across both instances. Coordination between the two entities’ finance teams is operationally non-negotiable.

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

    subgraph INST_A_CLOSE["Instance A Period-End"]
        A1["CATSCO Transfer<br>All Approved Time to CO"]
        A2["KSII Actual Activity<br>Price Calculation"]
        A3["KSS2 Cost Centre<br>Assessment and Distribution"]
        A4["DP91 RRB Billing<br>Request Generation"]
        A5["VF01 / VF04<br>IC Invoice Creation"]
        A6["FI Period Close<br>Company A"]
    end

    subgraph TRANSMIT["Cross-Instance Transmission"]
        T1["IDoc INVOIC02<br>or CPI iFlow"]
    end

    subgraph INST_B_CLOSE["Instance B Period-End"]
        B1["MIRO IC AP Invoice<br>Posting to WBS"]
        B2["CJ88 WBS Settlement<br>to AuC"]
        B3["AFAB Depreciation Run<br>on Active Assets"]
        B4["FI Period Close<br>Company B"]
    end

    subgraph CONSOL["Group Consolidation"]
        C1["BW/4HANA Extraction<br>Both Instances"]
        C2["IC Elimination<br>AR vs AP"]
        C3["SAC Group Reporting"]
    end

    A1 --> A2 --> A3 --> A4 --> A5 --> A6
    A5 --> T1
    T1 --> B1
    B1 --> B2 --> B3 --> B4
    B4 --> C1
    A6 --> C1
    C1 --> C2 --> C3

    class A1,A2,A3,A4,A5,A6 structure
    class T1 integration
    class B1,B2,B3,B4 finance
    class C1,C2,C3 reporting

Seq	Instance	Transaction	Dependency	Output
1	A	`CATSCO`	All time approved in external system and CATS	Actual hours posted to CO as activity confirmations
2	A	`KSII`	CATSCO complete	Actual activity price calculated per cost centre and activity type
3	A	`KSS2` / `KSV5`	KSII complete	Overhead distributed to proxy WBS
4	A	`DP91`	All costs on proxy WBS settled in ACDOCA	RRB billing requests generated per IC customer per WBS
5	A	`VF04` / `VF01`	DP91 billing requests exist	IC invoices created; AR raised in Company A
6	A	FI period close	All AR posted	Company A books closed
7	Transit	IDoc / CPI	VF01 output condition triggered	IC invoice transmitted to Instance B
8	B	`MIRO`	IDoc received and processed	IC AP invoice posted to WBS in Company B
9	B	`CJ88`	MIRO complete	WBS settled to AuC
10	B	`AFAB`	CJ88 complete	Depreciation posted on active assets
11	B	FI period close	AFAB complete	Company B books closed
12	Both	BW/4HANA extract	Both instances closed	ACDOCA delta extracted from both instances
13	Consolidation	IC elimination	BW extraction complete	IC AR and AP eliminated at group level
14	Consolidation	SAC reporting	Elimination complete	Group CapEx report and balance sheet available

Timing Mismatch Mitigations

Risk	Mitigation
IC invoice arrives in Company B after period close	Post manual accrual in Company B before close based on estimated IC charges; reverse when invoice arrives. Alternatively configure a late posting window in the FI fiscal year variant.
CATS records not approved before CATSCO run	CATS workflow auto-escalation at T-3 days. DP91 can run multiple times; DIP update flag prevents double billing. Prior-period CATS posting allowed within profile date tolerance.
Proxy WBS reference mismatch	Automate proxy WBS creation via `API_PROJECT_V3` event trigger in CPI when real WBS is created in Instance B. Enforce cross-instance WBS naming convention.

Reporting: Who Sees What and Where

Stakeholder	Need	System	Data Source
Employee (Company A)	Confirmed hours, project allocation, approval status	Kronos / Workday / SAP Fiori My Timesheet (`F3074`)	CATSDB
Project Controller (Company A)	Actual costs on proxy WBS, unbilled amounts, DP91 status	`CJ20N`, `S_ALR_87013558`, `DP91`	ACDOCA Instance A
Finance (Company A)	IC AR balances, open billing requests, period status	`VF05`, `FBL5N`	SD / FI Instance A
Project Controller (Company B)	Actual costs on WBS including IC charges, budget vs actual, AuC balance	`CJ20N`, `CJI3`, `S_ALR_87013558`	ACDOCA Instance B
Finance (Company B)	IC AP balances, WBS cost accumulation, AuC movements	`FBL1N`, `AW01N`	FI / FI-AA Instance B
CapEx Program Manager	Cross-entity cost roll-up, hours by entity, forecast vs actual	SAC Analytics Cloud	BW/4HANA consolidated
Group Finance	IC eliminations, CapEx balance sheet additions, group WIP	SAC Group Reporting	BW/4HANA + ACDOCC

The Chargeback as a Standard Process Flow

The complete cross-instance labour chargeback — time capture through capitalisation and group elimination — as a BPMN 2.0 process:

<?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_Ps1RrbChargeback"
                  targetNamespace="https://docs.sajivfrancis.com/bpmn">
  <bpmn:process id="Process_RrbCrossInstanceChargeback" name="RRB Cross-Instance Labour Chargeback" isExecutable="false">
    <bpmn:startEvent id="Start_WorkPerformed" name="Employee performs project work (home entity)">
      <bpmn:outgoing>Flow_1</bpmn:outgoing>
    </bpmn:startEvent>
    <bpmn:task id="Task_RecordTime" name="Record time in CATS (CAT2 / external system via CPI)">
      <bpmn:incoming>Flow_1</bpmn:incoming>
      <bpmn:outgoing>Flow_2</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_TransferCo" name="Transfer approved time to Controlling (CATSCO)">
      <bpmn:incoming>Flow_2</bpmn:incoming>
      <bpmn:outgoing>Flow_3</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Dp91" name="Create debit memo request from actuals (DP91, DIP profile)">
      <bpmn:incoming>Flow_3</bpmn:incoming>
      <bpmn:outgoing>Flow_4</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Vf01" name="Bill intercompany invoice (VF01, IC billing type)">
      <bpmn:incoming>Flow_4</bpmn:incoming>
      <bpmn:outgoing>Flow_5</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Transmit" name="Transmit IC invoice (IDoc INVOIC / CPI iFlow)">
      <bpmn:incoming>Flow_5</bpmn:incoming>
      <bpmn:outgoing>Flow_6</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_PostAp" name="Post AP against project WBS (receiving instance)">
      <bpmn:incoming>Flow_6</bpmn:incoming>
      <bpmn:outgoing>Flow_7</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Settle" name="Settle WBS to AuC (CJ88)">
      <bpmn:incoming>Flow_7</bpmn:incoming>
      <bpmn:outgoing>Flow_8</bpmn:outgoing>
    </bpmn:task>
    <bpmn:task id="Task_Eliminate" name="Eliminate IC AR/AP pair at group consolidation">
      <bpmn:incoming>Flow_8</bpmn:incoming>
      <bpmn:outgoing>Flow_9</bpmn:outgoing>
    </bpmn:task>
    <bpmn:endEvent id="End_Capitalised" name="Cost capitalised in project-owning entity">
      <bpmn:incoming>Flow_9</bpmn:incoming>
    </bpmn:endEvent>
    <bpmn:sequenceFlow id="Flow_1" sourceRef="Start_WorkPerformed" targetRef="Task_RecordTime" />
    <bpmn:sequenceFlow id="Flow_2" sourceRef="Task_RecordTime" targetRef="Task_TransferCo" />
    <bpmn:sequenceFlow id="Flow_3" sourceRef="Task_TransferCo" targetRef="Task_Dp91" />
    <bpmn:sequenceFlow id="Flow_4" sourceRef="Task_Dp91" targetRef="Task_Vf01" />
    <bpmn:sequenceFlow id="Flow_5" sourceRef="Task_Vf01" targetRef="Task_Transmit" />
    <bpmn:sequenceFlow id="Flow_6" sourceRef="Task_Transmit" targetRef="Task_PostAp" />
    <bpmn:sequenceFlow id="Flow_7" sourceRef="Task_PostAp" targetRef="Task_Settle" />
    <bpmn:sequenceFlow id="Flow_8" sourceRef="Task_Settle" targetRef="Task_Eliminate" />
    <bpmn:sequenceFlow id="Flow_9" sourceRef="Task_Eliminate" targetRef="End_Capitalised" />
  </bpmn:process>
  <bpmndi:BPMNDiagram id="Diagram_Process_RrbCrossInstanceChargeback">
    <bpmndi:BPMNPlane id="Plane_Process_RrbCrossInstanceChargeback" bpmnElement="Process_RrbCrossInstanceChargeback">
      <bpmndi:BPMNShape id="Shape_Start_WorkPerformed" bpmnElement="Start_WorkPerformed">
        <dc:Bounds x="202" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_RecordTime" bpmnElement="Task_RecordTime">
        <dc:Bounds x="330" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_TransferCo" bpmnElement="Task_TransferCo">
        <dc:Bounds x="500" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Dp91" bpmnElement="Task_Dp91">
        <dc:Bounds x="670" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Vf01" bpmnElement="Task_Vf01">
        <dc:Bounds x="840" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Transmit" bpmnElement="Task_Transmit">
        <dc:Bounds x="1010" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_PostAp" bpmnElement="Task_PostAp">
        <dc:Bounds x="1180" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Settle" bpmnElement="Task_Settle">
        <dc:Bounds x="1350" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_Task_Eliminate" bpmnElement="Task_Eliminate">
        <dc:Bounds x="1520" y="220" width="120" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Shape_End_Capitalised" bpmnElement="End_Capitalised">
        <dc:Bounds x="1732" y="242" width="36" height="36" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNEdge id="Edge_Flow_1" bpmnElement="Flow_1">
        <di:waypoint x="238" y="260" />
        <di:waypoint x="330" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_2" bpmnElement="Flow_2">
        <di:waypoint x="450" y="260" />
        <di:waypoint x="500" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_3" bpmnElement="Flow_3">
        <di:waypoint x="620" y="260" />
        <di:waypoint x="670" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_4" bpmnElement="Flow_4">
        <di:waypoint x="790" y="260" />
        <di:waypoint x="840" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_5" bpmnElement="Flow_5">
        <di:waypoint x="960" y="260" />
        <di:waypoint x="1010" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_6" bpmnElement="Flow_6">
        <di:waypoint x="1130" y="260" />
        <di:waypoint x="1180" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_7" bpmnElement="Flow_7">
        <di:waypoint x="1300" y="260" />
        <di:waypoint x="1350" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_8" bpmnElement="Flow_8">
        <di:waypoint x="1470" y="260" />
        <di:waypoint x="1520" y="260" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Edge_Flow_9" bpmnElement="Flow_9">
        <di:waypoint x="1640" y="260" />
        <di:waypoint x="1732" y="260" />
      </bpmndi:BPMNEdge>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</bpmn:definitions>

Recommendation and Conclusion

The Eight Design Decisions

Before entering build, every cross-instance RRB CapEx program must resolve these eight questions. They determine the configuration path completely.

#	Question	Options	Impact
1	Are both entities on the same S/4HANA instance?	Same instance vs. separate instances	Determines whether proxy WBS is needed and whether CO area can be shared
2	Is there a single CO area spanning both company codes?	Single CO area vs. separate CO areas	Determines whether CATS can post directly to the project-owning entity’s WBS
3	What is the enterprise time system?	Kronos, Workday, Fieldglass, SAP CAT2, or combination	Determines which CPI iFlow to build or configure
4	Is HR on SAP HCM or SuccessFactors?	SAP HCM on-premise vs. SuccessFactors Employee Central	Determines PERNR resolution strategy
5	What is the IC pricing model?	Cost pass-through vs. fixed rate vs. marked-up rate	Determines DIP profile quantity setting and VK11 condition record structure
6	Are contractors in scope?	Employees only vs. employees and contractors	Determines whether Fieldglass SES path is included in the DIP profile
7	What is the capitalisation trigger?	Periodic settlement vs. milestone-driven vs. project completion	Determines CJ88 and AIBU scheduling
8	What is the consolidation tool?	SAP Group Reporting vs. BPC vs. BW/4HANA with SAC	Determines IC elimination approach and cross-instance extract design

Implementation Sequence

Phase	Duration	Key Activities
1 — Foundation	Weeks 1–4	CO area, company code config, trading partner, activity type and cost centre master data
2 — HR and CATS	Weeks 3–6	CATS profiles, employee groupings, activity type defaults, PERNR mapping in CPI, CATSCO batch setup
3 — PS Structure	Weeks 4–8	Project profiles, WBS hierarchy, proxy WBS naming convention, budget profiles, settlement profiles
4 — RRB and DIP	Weeks 7–10	DIP profile (ACDOCA source), material determination, IC pricing procedure, VK11 condition records
5 — IC SD Setup	Weeks 8–11	IC sales org, IC order and billing types, IC customer and vendor master, output type for IDoc
6 — Integration	Weeks 9–13	CPI iFlows for time routing, PERNR resolution, WBS sync, IC invoice transmission; IDoc partner profiles
7 — FI-AA	Weeks 10–13	AuC asset class, investment profiles, depreciation areas, AIAB and AIBU configuration
8 — Testing	Weeks 12–16	End-to-end: time entry through CATSCO through DIP through IC invoice through WBS through AuC through capitalisation through BW extract
9 — Reporting	Weeks 14–17	BW/4HANA datasources from both instances, IC elimination logic, SAC CapEx dashboard
10 — Cutover	Weeks 16–18	Open WBS balance migration, AuC balance transfer, proxy WBS population, go-live

The Central Conclusion

The architecture described in this whitepaper resolves a problem that is often handled badly — through HR workarounds, manual journal entries, or spreadsheet-based labour allocations that leave no audit trail and create consolidation headaches. SAP Project System with RRB is purpose-built for exactly this scenario.

The decisive architectural insight is that the intercompany boundary is a financial and legal construct, not an HR or operational one. Employees work where they work. The question is how their effort is priced, billed, and capitalised across entity lines — and RRB answers that question natively, with a complete SD billing document as the legal instrument, ACDOCA as the audit trail on both sides, and BW/4HANA as the cross-instance view.

Three implementation choices determine whether this architecture succeeds or becomes a maintenance burden. First, configure the DIP profile to source from ACDOCA — not COEP — on any S/4HANA 2022 or later deployment. Second, invest in the CPI integration layer properly: the labour code to activity type mapping and PERNR resolution logic are where most cross-instance RRB projects accumulate technical debt if shortcuts are taken. Third, enforce a coordinated period-end calendar between the executing and project-owning entities from day one — the dependency chain from CATSCO through to Company B’s FI close is strict, and timing mismatches are the most common operational failure mode once the system is live.

Executed correctly, the result is a capital expenditure program where an engineer clocks time in Kronos on a Monday morning, that time is valued at the agreed intercompany rate, invoiced to the project-owning entity by Friday, posted to a WBS element that settles monthly to an Asset under Construction, and ultimately capitalises to a fixed asset on the project-owning entity’s balance sheet — with the intercompany pair eliminated cleanly at group consolidation. No employee moves. No HR replication. No manual journals. That is what this architecture is designed to deliver.

Continue to Part 2 — Funded CapEx: Parent Financing, MFG Asset Acquisition, and Multi-GAAP Settlement, which extends this architecture to the case where funding originates in one entity and the asset is acquired and operated in another — covering IC loan / IM budget / grant instruments, IAS 23 borrowing-cost capitalisation, multi-GAAP depreciation, transfer pricing, and group consolidation. Part 3 — Centralised AuC with Intercompany Asset Transfer at Capitalisation covers the reverse pattern: the asset is built centrally and transferred to the operating segment at completion.