Freight Settlement in SAP TM: From Charge Calculation to Posting in ERP

Charge calculation is where most SAP TM projects spend their energy: freight agreements, calculation sheets, rate tables, scales. Yet the moment the carrier invoice arrives, the question that actually matters to Finance is a different one: did the planned cost reach the ERP, was it accrued in the right period, and can the invoice be verified against it without manual work?

That is the job of the Freight Settlement Document (FSD). In this article we walk through its complete lifecycle, from the Freight Order to the posted invoice, and list the blockers we keep meeting on projects, with where to look for each one.

1) What the Freight Settlement Document is, and what it is not

The FSD is the TM document that represents what we owe a carrier for one or more Freight Orders or Freight Bookings. Technically it is the business object /SCMTMS/SUPPFREIGHTINVREQ, the Supplier Freight Invoice Request, which is why many report and class names carry the prefix SFIR.

Two things it is not:

• It is not the carrier invoice. The invoice is verified in MM (Logistics Invoice Verification). The FSD is the expected cost that the invoice will be matched against.
• It is not the customer-side settlement. Billing freight to your own customers goes through the Forwarding Settlement Document (CFIR), which hands over to SD billing. Different object, different integration, different article.

2) The end-to-end flow

In an embedded TM landscape (S/4HANA with TM in the same system) the flow looks like this:

Step	Where it happens	Result
Charge calculation	Freight Order / Freight Booking	Charge lines with amounts per charge type
FSD creation	TM (manual, from the FO, or in batch)	FSD with items per charge type and cost distribution
Transfer to ERP (posting)	TM to MM	Service purchase order and service entry sheet (accrual)
Invoice verification	MM, invoice verification	Supplier invoice matched to the purchase order / service entry sheet
Status update	MM to TM	FSD invoicing status updated; differences visible in TM

In a side-by-side landscape (SAP TM 9.x connected to a separate ERP) the same steps exist, but the transfer runs through the enterprise services for invoicing preparation, so most of the troubleshooting moves to the service monitoring and the ERP inbound processing. Everything below focuses on the embedded scenario; verify the equivalent objects if you run side-by-side.

3) Step 1 – Make the Freight Order settlement-ready

Before an FSD can be created, the Freight Order type must allow it, and the document must be in a state that your business accepts for settlement.

• Settlement profile assigned to the Freight Order type. The profile controls, among other things, whether cost distribution is active and how FSD items are grouped.
• Execution status prerequisite. Many customers want to settle only after execution is complete, others want to accrue when the Freight Order is confirmed to the carrier. This is a setting on the Freight Order type; decide it with Finance, not with the planners.
• Charges calculated without errors. An FO with a charge calculation error produces no FSD, or produces one with zero amounts. The charge calculation log on the FO is the first place to look.
• Carrier assigned with a valid business partner that is also a supplier in MM. A carrier that only exists as a TM business partner cannot receive a purchase order.

4) Step 2 – Create the FSD: manual or batch

From a single Freight Order you can create the FSD directly from the document UI or from the Freight Order worklist. In productive operation, however, FSDs are created in background: the report /SCMTMS/SFIR_CREATE_BATCH (Create Freight Settlement Documents in background) selects Freight Orders by type, carrier, date and status and creates one FSD per order or grouped per carrier, depending on the settlement profile.

What the FSD contains at this point:

• Header: carrier, purchasing organization, currency, settlement document type, lifecycle status.
• Items: one per charge type (base freight, fuel surcharge, toll, waiting time, and so on), each with amount and the charge type to service mapping that MM will need.
• Cost distribution (if active): how each amount splits across the deliveries or sales orders inside the Freight Order, so Finance can see freight cost per shipment, per customer or per profitability segment instead of one lump sum per truck.

Review the FSD before transferring it during the first weeks of go-live. Once teams trust the numbers, chain creation and transfer in one job.

5) Step 3 – Transfer to ERP: purchase order and service entry sheet

Transferring (posting) an FSD triggers two MM documents:

1. A service purchase order for the carrier, with one service line per FSD item. The purchasing organization and purchasing group come from the settlement configuration (organizational unit mapping), and each TM charge type must be mapped to a service master record or product, otherwise MM has nothing to buy.
2. A service entry sheet, which is accepted automatically. The acceptance is the accrual: this is the posting that puts the freight cost into the period, against the account assignment derived from the cost distribution (cost center, internal order, profitability segment, or the sales order items themselves).

The batch equivalent is /SCMTMS/SFIR_TRANSFER_BATCH. After a successful transfer the FSD shows the purchase order and service entry sheet numbers in its document flow, and the lifecycle status moves on; if the transfer failed, the FSD keeps the error messages in the application log, so always read that log before touching the MM side.

6) Step 4 – Invoice verification and the way back to TM

The carrier invoice is now entered in MM invoice verification referencing the purchase order (or the service entry sheet). Three practical setups we have used:

• Manual verification: the AP team keys the invoice; price differences trigger the normal MM tolerance checks and blocking.
• Evaluated receipt settlement (ERS): the system creates the invoice from the accepted service entry sheet. This is the “self-billing” model and only works when the carrier accepts your calculated amount as the invoice basis. Very effective for spot and contract carriers with clean agreements.
• Electronic invoice inbound (for example from a carrier portal or a supplier collaboration platform) posted against the purchase order.

Once the invoice is posted, the invoicing status flows back to the FSD, so from TM you can see which Freight Orders are accrued, invoiced or still open. If the invoice amount differs from the accrual and your process accepts the difference, the usual approach is to adjust the charges in TM, cancel and recreate the FSD (or create a delta FSD), and let MM post the correction rather than editing the purchase order by hand. Editing the MM documents directly breaks the link TM relies on.

7) Reading the FSD programmatically

When you need to report on settlement data or build a check in a custom process, read the business object with the BOPF API instead of guessing table names. A minimal retrieval of the root node looks like this (constants interface name to be verified in your release):

DATA(lo_srv) = /bobf/cl_tra_serv_mgr_factory=>get_service_manager(
                 /scmtms/if_sfir_c=>sc_bo_key ).

lo_srv->retrieve(
  EXPORTING iv_node_key = /scmtms/if_sfir_c=>sc_node-root
            it_key      = lt_sfir_keys          " keys of the FSDs
  IMPORTING et_data     = lt_sfir_root ).       " /scmtms/t_sfir_root_k

LOOP AT lt_sfir_root ASSIGNING FIELD-SYMBOL(<ls_root>).
  " -lifecycle, invoicing status, carrier, total amount ...
ENDLOOP.

The document flow to the purchase order and service entry sheet is available as an association from the root node, which is also how the standard UI builds the “Document Flow” tab.

8) Troubleshooting checklist

The blockers below cover most of the tickets we have seen on freight settlement:

• “No FSD created” for an FO: check Freight Order type (settlement allowed, status prerequisite), charge calculation log, and whether the FO already has an FSD in a status that blocks a new one.
• Transfer error “purchasing organization could not be determined”: the organizational unit mapping from TM purchasing org to MM purchasing org / group is missing for this company code.
• “No service or product assigned to charge type”: a new charge type was added to the calculation sheet and nobody mapped it to a service master. Every charge type that can appear on an FSD needs a mapping.
• Account assignment errors on the service entry sheet: usually cost distribution produced a reference (sales order item, cost center) that is closed or not valid for the posting date; look at the distribution items on the FSD, not at the PO.
• Currency or exchange rate differences: the FSD posts in the agreement currency; the purchase order may convert to company code currency on a different date. Align the exchange rate type and the posting date logic with Finance early.
• Status stuck after invoice posting: the invoicing status update did not reach TM. In embedded TM this is rare and normally points to a failed background update; in side-by-side landscapes check the service monitoring first.

Conclusion

Freight settlement is where TM meets Finance, and most of the pain comes from treating it as an afterthought of charge calculation. Agree with Finance when the accrual should happen, map every charge type to a service master before the first FSD is created, activate cost distribution if anyone will ever ask “how much freight did this customer cost us”, and read the FSD application log before touching anything in MM. Done this way, the FSD becomes a reliable bridge rather than a monthly reconciliation exercise.

If you run a different setup, for example ERS with hundreds of carriers or a side-by-side landscape, share your experience in the comments.