Many times I get asked how the freight cost allocation needs to be configured and what are the correct  Use Case Types, Settlement Process Types, Pricing Procedures etc. in SAP TM and specially from those customers who have moved from LE-TRA or SAP TM 9.5 or who have upgraded from SAP S/4HANA lower releases to latest SAP S/4HANA 2025, dont understand what has changed in this process. In this blog I try to clarify these to best of my ability and experience.

SAP Transportation Management's Freight Cost Allocation (FCA) business process — business process category 2FCA — has evolved through three distinct phases. Each phase introduced different settlement document types configured in table TMFK, driven by tighter integration with S/4HANA's Financial Accounting and Material Ledger. A critical technical dimension of this evolution — the USE_CASE field in view WZRE_V_DATA — acts as the routing key that determines how Settlement Management processes and posts each document.

Phase 1 — Legacy

Settlement document types: 1600 & 1601

Cost Distribution on G/L – TM
USE_CASE=30 · FR2 account key
Generic settlement, not FCA-branded

Phase 2 — First FCA Types

Settlement document types: 2TM1 & 2TM2

Freight Cost Allocation (Expense)
USE_CASE=31 · AXX003 pricing
TM1 account key · FCA BO introduced

Phase 3 — ML-Account FCA

Settlement document types: 2TM3 & 2TM4

Freight Cost Allocation (ML-Account)
USE_CASE=30 · WT0001 pricing
TM1 account key · ML integration

Current Recommendation

Settlement document types: 2TM3 / 2TM4

Preferred in S/4HANA with mandatory ML actual costing (CKMLCP)

Phase 1: Document Types 1600 & 1601 — “Cost Distribution on G/L”

Concept: The original approach treated freight cost allocation as a generic G/L cost distribution. There was no dedicated “FCA” identity — 1600/1601 used the same settlement infrastructure as other non-FCA settlement processes. The process type WRART=1600 maps directly to LFART=1600 (same value), indicating an early, undifferentiated design with no separation between process definition and document type.

USE_CASE=30 / WT0001: The standard TM settlement pricing procedure WT0001 was used. No FCA-specific pricing conditions existed. The G/L account posting was driven by the generic FR2 account key (Freight General Clearing).

RFBFK=X on 1600: The invoice type had the FI posting block active, requiring a manual release before FI documents were generated. This was intentional to allow review before financial posting.

KTOSL_VE=FR2: A generic freight clearing account key — not TM-specific. Linked to standard freight G/L accounts in account determination, shared across multiple settlement scenarios.

AGENCY_DOC_CAT=2 (Debit): The document was modeled as a debit posting (outgoing cost). Later types switched to AGENCY_DOC_CAT=1 (credit/invoice model), reflecting a modernized document flow design.

Limitations: (1) No FCA identity — LFART_TYPE blank, SEMANTIC_TYPE=0000. (2) No distinction between ML-based and expense-based scenarios. (3) Generic FR2 account key prevents TM-specific G/L account differentiation.

Phase 2: Document Types 2TM1 & 2TM2 — “First Proper FCA Types (Expense)”

Major Advancement: Introduction of proper FCA identity and a dedicated expense posting path. The new WRART=2TME is distinct from LFART=2TM1, cleanly separating process definition from document type.

USE_CASE=31 (New Expense Path!): A dedicated FCA expense pricing procedure AXX003 was introduced. This is the most significant change in Phase 2: AXX003 contains condition types designed to post freight costs as operating expenses to P&L accounts, cost centers, profit centers, or internal orders — not to balance sheet or inventory accounts.

LFART_TYPE=B: The FCA-specific variant indicator was introduced. This enables variant-based processing rules in Settlement Management specific to the FCA scenario.

SEMANTIC_TYPE=0013: FCA-specific semantic rules were activated. This enables FCA-specific business logic, validations, and reporting capabilities that do not apply to generic settlement processes.

RFBFK=blank: The FI posting block was removed for 2TM1. Settlement documents post directly to FI without manual release, accelerating the expense allocation cycle.

Account Key TM1: A new TM-specific clearing account key (TM1) replaced FR2, enabling dedicated G/L account assignment exclusively for TM FCA postings.

Why 2TM1/2TM2 were insufficient for ML scenarios: The AXX003 pricing procedure and USE_CASE=31 route costs to expense accounts. In S/4HANA environments where Material Ledger actual costing (CKMLCP) is active, freight costs must flow through ML-relevant accounts — not be posted as period expenses. 2TM1/2TM2 could not satisfy this ML integration requirement. Additionally, the missing RFBFK block meant FI was posted immediately without the controlled period-end timing that ML costing requires.

Phase 3: Document Types 2TM3 & 2TM4 — “ML-Account FCA (Current Preferred)”

Purpose: Complete the FCA picture by providing dedicated document types for the Material Ledger integration scenario — mandatory in most S/4HANA production implementations.

USE_CASE=30 (Returns to ML/GL path): The 2TM3/2TM4 types deliberately revert to USE_CASE=30 and pricing procedure WT0001. WT0001 contains the condition types needed to post to ML-relevant G/L accounts. The difference from old 1600 is the new TM1 account key, new WRART (2TMM vs 1600), and AGENCY_DOC_CAT=1.

RFBFK=X reinstated on 2TM3: The posting block is re-introduced for the invoice type. This is critical for ML integration: the settlement document is created and held, allowing the ML actual costing run (CKMLCP) to capture and process it at the correct time during period-end close. The reversal type (2TM4) correctly has no block.

LFART_TYPE=B maintained: The FCA variant designation is preserved, consistent with all post-Phase-1 types.

SEMANTIC_TYPE=0000 (Generic): Unlike 2TM1/2TM2, the ML-Account types do not use FCA-specific semantic overrides. The ML posting path follows standard settlement rules. The account determination (TM1 key) ensures correctness without requiring FCA semantic business logic.

Expanded REF_DOC_TYPE coverage: REF_DOC_TYPE 12 (Sales Order / Contract), 13 (Delivery) , 15 (Inbound Delivery) , and 17 (Purchase Order / Contract)  are supported — the same as old 1600 — giving full coverage (compared to the narrower 12 (Sales Order) / 13 (Delivery)  in Phase 2).

Enjoy reading !!!