SAP Global Trade Services — Part 3: Customs Declarations, Duty Accounting, Preference Certificates & Migration

This is the third installment of a three-part series. Part 1 covered architecture, organizational structure, master data, and the compliance backbone. Part 2 covered customs execution, special procedures, and preference management. Part 3 closes the loop: from the customs declaration GTS files, to the duty liability that posts to FI-CO, to the preference certificate that eliminates it, through to the Software Update Manager migration path that gets an organization from SAP GTS 11.0 to SAP GTS, edition for SAP HANA.

Executive Summary

SAP GTS, edition for SAP HANA is not a monolithic compliance gate — it is a structured integration of five functional pillars that, together, govern every trade event from the moment a sales order is placed to the moment duty is paid or eliminated. This paper completes the series by addressing the three areas most often treated as afterthoughts in GTS implementations: the mechanics of how a customs declaration translates into a financial posting in FI-CO; the certificate lifecycle that converts a preference determination result into a document a customer can actually use at the border; and the migration program that gets an organization from a classic GTS instance onto the HANA edition.

The declaration-to-ledger loop is technically complete in GTS but requires deliberate integration design to close. The preference certificate is a living instrument, not a one-time deliverable — BOM changes, vendor LTSD updates, and agreement amendments all create reissuance obligations that GTS can track if the system is configured to do so. And the migration to the HANA edition is, in practice, a custom code audit first and a technical upgrade second: the SUM/DMO process is well-defined, but BAdI inventories and transport scopes are where timelines slip.

Context

Parts 1 and 2 of this series established the structural and operational foundations of SAP GTS. Part 1 described how GTS models a multinational organization through Foreign Trade Organizations (FTOs), how its compliance engine screens every business partner and product against sanctioned-party lists and embargo tables, and how the feeder system integration via IDocs and RFC keeps GTS synchronized with S/4HANA in near real-time. Part 2 walked through the customs execution lifecycle — export and import declarations, the e-filing communication scheme, special procedures including inward processing, bonded warehouse, and EMCS — and then turned to preference management: how GTS determines whether a product qualifies under a free trade agreement using either top-down (product costing–driven) or bottom-up (vendor declaration–driven) calculation logic.

What Part 2 did not fully address is what happens after those processes complete. A released customs declaration creates a financial liability. A successful preference determination creates an obligation to issue a certificate. A GTS system running on a classic stack eventually needs to move to the HANA edition to stay current on Fiori applications, embedded analytics, and the annual legal-change packages SAP now delivers only on that platform. This paper addresses all three.

From Declaration to Ledger: The Duty Accounting Loop

How the Customs Declaration Posts to FI

SAP GTS does not post directly to FI-CO. The financial impact of a customs declaration flows back through the feeder system — S/4HANA — through a defined integration path that uses planned delivery costs as the mechanism for capturing assessed duty at the line-item level.

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

    subgraph GTS_LAYER["SAP GTS — Customs Management"]
        CD["Customs Declaration<br>(Import / Export)"]
        DutyCalc["Duty Calculation<br>(Duty Type + Procedure)"]
        Status["Declaration Status<br>(Released / Rejected)"]
        CD --> DutyCalc --> Status
    end

    subgraph INT_LAYER["Integration — IDocs / BAPIs"]
        IDoc["IDoc: CUSDEC<br>Outbound / Inbound"]
        StatusMsg["Status Message<br>(E-Filing Callback)"]
    end

    subgraph S4_LAYER["S/4HANA — FI-CO"]
        GR["Goods Receipt<br>(MIGO)"]
        IR["Invoice Receipt<br>(MIRO)"]
        DutyAccrual["Duty Accrual<br>(Planned Delivery Cost)"]
        ActualPosting["Actual Duty Posting<br>(GR/IR Clearing)"]
        CO["CO Cost Object<br>(Cost Center / Order)"]
        GR --> DutyAccrual
        IR --> ActualPosting
        DutyAccrual --> CO
        ActualPosting --> CO
    end

    subgraph REPORT["Analytics"]
        Embedded["Embedded Analytics<br>(GTS Reports)"]
        BW["SAP BW/4HANA<br>or Datasphere"]
    end

    Status -->|"declaration released"| IDoc
    IDoc --> GR
    IDoc --> IR
    StatusMsg --> Status
    GTS_LAYER -->|"duty value & tariff"| INT_LAYER
    S4_LAYER -->|"actuals feed"| REPORT
    GTS_LAYER -->|"classified document data"| REPORT

    class CD,DutyCalc,Status gts
    class GR,IR,DutyAccrual,ActualPosting,CO fi
    class IDoc,StatusMsg integration
    class Embedded,BW reporting

The critical handoff points vary by declaration type:

Trigger	GTS Event	S/4HANA Event	FI Document Type
Import declaration released	Duty framework finalized	Goods Receipt (MIGO)	WE — Goods Receipt
Customs broker invoice received	Broker communication closed	MIRO — Planned delivery cost	RE — Invoice Receipt
Export EAD issued	Export declaration set to “Released”	Billing document posted	RV — Billing
Rejection / re-assessment	Status callback inbound	Reversal / correction	Depends on process

The design implication is important: because duty liability surfaces in S/4HANA as a planned delivery cost rather than as a direct posting from GTS, the purchasing info record or condition type carrying that planned cost must be configured to the correct GL account and cost object before any declarations are filed. Retrofitting the FI integration after declarations have been processed creates a reconciliation problem that is both time-consuming and auditor-facing.

Duty Calculation Framework

GTS calculates duty at the customs declaration item level using a configurable duty framework built from three Customizing layers. Duty Types are the atomic unit — ad valorem, specific, anti-dumping, countervailing — each carrying a calculation base (customs value, net weight, quantity). A Calculation Procedure assembles an ordered sequence of duty types applied to each item, analogous to a pricing procedure in SD. Duty Type Mapping then reconciles external codes received from customs authorities — via IDoc from a broker, for example — to internal GTS duty types, enabling a comparison of assessed versus calculated duty.

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

    ExtDuty["External Duty Type<br>(Customs Authority Code)"]
    Mapping["Duty Type Mapping<br>(IMG Customizing)"]
    IntDuty["Internal Duty Type<br>(GTS)"]
    CalcProc["Calculation Procedure<br>(Ordered Steps)"]
    DutyAmt["Duty Amount<br>(per Declaration Item)"]
    ImportDF["Import Duty Framework<br>(Header + Item)"]

    ExtDuty -->|"mapped via IMG"| Mapping
    Mapping --> IntDuty
    IntDuty --> CalcProc
    CalcProc --> DutyAmt
    DutyAmt --> ImportDF

    class ExtDuty source
    class Mapping integration
    class IntDuty,CalcProc,DutyAmt,ImportDF target

The Import Duty Framework in GTS shows duty broken down to the item level — each item carries its tariff number, assessed customs value, applicable duty rate, and computed duty amount. That granularity is what enables a reconciliation between what GTS calculated and what the customs authority assessed.

Exchange Rates in Customs Declarations

Customs authorities in most jurisdictions require the customs value to be expressed in local currency at a rate published by that authority — typically weekly or monthly — not the rate SAP uses for financial postings. GTS maintains a separate Customs Exchange Rate table that is loaded periodically and applied to declaration items independent of the S/4HANA exchange rate type. This creates a deliberate delta between the customs value and the FI posting value, a gap that must be understood and documented for transfer pricing and deferred duty calculations alike. It is not a defect; it is a legal requirement. The documentation obligation is on the organization.

The Customs Declaration Lifecycle End-to-End

Export Declaration: Business and System Process

The export declaration lifecycle in GTS is triggered by a billing document or delivery in S/4HANA and culminates in the receipt of an Electronic Administrative Document (EAD) from the customs authority. The e-filing communication scheme governs the message sequence: a two-message handshake in which the authority first acknowledges receipt and assigns a Movement Reference Number (MRN), then issues the release confirmation. GTS tracks both messages through its Communication Process framework — Action Profiles, Action Definitions, Processing Types, Message Schema — all configured under Customs Management in Customizing.

<?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="ExportDeclaration" targetNamespace="http://sajivfrancis.com/gts">
  <bpmn:process id="proc_export_decl" isExecutable="false" name="GTS Export Declaration — E-Filing">

    <bpmn:startEvent id="SE_BillingDoc" name="Billing Document Posted in S/4HANA">
      <bpmn:outgoing>sf1</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:task id="T_Replicate" name="Replicate Billing Doc to GTS Customs Document">
      <bpmn:incoming>sf1</bpmn:incoming>
      <bpmn:outgoing>sf2</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Complete" name="Complete Declaration Data (Manage Export Declarations — Fiori)">
      <bpmn:incoming>sf2</bpmn:incoming>
      <bpmn:incoming>sf_fix</bpmn:incoming>
      <bpmn:outgoing>sf3</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="GW_Complete" name="Completeness Check Passed?">
      <bpmn:incoming>sf3</bpmn:incoming>
      <bpmn:outgoing>sf4_yes</bpmn:outgoing>
      <bpmn:outgoing>sf4_no</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="T_Fix" name="Resolve Incompleteness Errors (Incompleteness Procedure)">
      <bpmn:incoming>sf4_no</bpmn:incoming>
      <bpmn:outgoing>sf_fix</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Transmit" name="Transmit Declaration to Customs Authority via EDI">
      <bpmn:incoming>sf4_yes</bpmn:incoming>
      <bpmn:incoming>sf_reject</bpmn:incoming>
      <bpmn:outgoing>sf5</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Recv1" name="Receive First Incoming Message (Registration Number / MRN)">
      <bpmn:incoming>sf5</bpmn:incoming>
      <bpmn:outgoing>sf6</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Recv2" name="Receive Second Confirmation Message (EAD / Release)">
      <bpmn:incoming>sf6</bpmn:incoming>
      <bpmn:outgoing>sf7</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="GW_Released" name="Declaration Released?">
      <bpmn:incoming>sf7</bpmn:incoming>
      <bpmn:outgoing>sf8_yes</bpmn:outgoing>
      <bpmn:outgoing>sf8_no</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="T_Reject" name="Handle Rejection — Amend and Resubmit">
      <bpmn:incoming>sf8_no</bpmn:incoming>
      <bpmn:outgoing>sf_reject</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Archive" name="Archive EAD — Update Customs Document Status">
      <bpmn:incoming>sf8_yes</bpmn:incoming>
      <bpmn:outgoing>sf9</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_FI" name="Trigger FI Posting in S/4HANA (GR/IR Clearing)">
      <bpmn:incoming>sf9</bpmn:incoming>
      <bpmn:outgoing>sf10</bpmn:outgoing>
    </bpmn:task>

    <bpmn:endEvent id="EE_Done" name="Export Cleared — FI Document Posted">
      <bpmn:incoming>sf10</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="sf1" sourceRef="SE_BillingDoc" targetRef="T_Replicate"/>
    <bpmn:sequenceFlow id="sf2" sourceRef="T_Replicate" targetRef="T_Complete"/>
    <bpmn:sequenceFlow id="sf3" sourceRef="T_Complete" targetRef="GW_Complete"/>
    <bpmn:sequenceFlow id="sf4_yes" name="Yes" sourceRef="GW_Complete" targetRef="T_Transmit"/>
    <bpmn:sequenceFlow id="sf4_no" name="No — incomplete" sourceRef="GW_Complete" targetRef="T_Fix"/>
    <bpmn:sequenceFlow id="sf_fix" sourceRef="T_Fix" targetRef="T_Complete"/>
    <bpmn:sequenceFlow id="sf5" sourceRef="T_Transmit" targetRef="T_Recv1"/>
    <bpmn:sequenceFlow id="sf6" sourceRef="T_Recv1" targetRef="T_Recv2"/>
    <bpmn:sequenceFlow id="sf7" sourceRef="T_Recv2" targetRef="GW_Released"/>
    <bpmn:sequenceFlow id="sf8_yes" name="Released" sourceRef="GW_Released" targetRef="T_Archive"/>
    <bpmn:sequenceFlow id="sf8_no" name="Rejected" sourceRef="GW_Released" targetRef="T_Reject"/>
    <bpmn:sequenceFlow id="sf_reject" sourceRef="T_Reject" targetRef="T_Transmit"/>
    <bpmn:sequenceFlow id="sf9" sourceRef="T_Archive" targetRef="T_FI"/>
    <bpmn:sequenceFlow id="sf10" sourceRef="T_FI" targetRef="EE_Done"/>
  </bpmn:process>
</bpmn:definitions>

Import Declaration: Two Sequencing Modes

Unlike export, import has a sequencing decision that must be made upfront: file the declaration after goods receipt, which is the common case for direct imports, or file before goods receipt, which is required when a customs broker files on behalf of the importer prior to physical arrival. GTS supports both modes, with a Customs Invoice or Customs Waybill serving as the pre-GR anchor document in the before-GR scenario.

Mode	Trigger Document	GTS Document Created From	Duty Framework Timing
After GR	MIGO — Goods Receipt	Purchase Order + Inbound Delivery	At declaration creation
Before GR (Invoice)	Customs Invoice	Customs Invoice Header + Item	At invoice entry; GR reconciles
Before GR (Waybill)	Customs Waybill	Purchase Order	At waybill creation

<?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="ImportDeclaration" targetNamespace="http://sajivfrancis.com/gts">
  <bpmn:process id="proc_import_decl" isExecutable="false" name="GTS Import Declaration — Before and After GR">

    <bpmn:startEvent id="SE_PO" name="Purchase Order Created in S/4HANA">
      <bpmn:outgoing>sf1</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:exclusiveGateway id="GW_Timing" name="Declaration Timing?">
      <bpmn:incoming>sf1</bpmn:incoming>
      <bpmn:outgoing>sf_before</bpmn:outgoing>
      <bpmn:outgoing>sf_after</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="T_Invoice" name="Create Customs Invoice or Waybill (Pre-GR Anchor)">
      <bpmn:incoming>sf_before</bpmn:incoming>
      <bpmn:outgoing>sf2b</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_GR" name="Post Goods Receipt (MIGO)">
      <bpmn:incoming>sf_after</bpmn:incoming>
      <bpmn:outgoing>sf2a</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_DeclBefore" name="Create Import Declaration — Before GR Worklist">
      <bpmn:incoming>sf2b</bpmn:incoming>
      <bpmn:outgoing>sf3b</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_DeclAfter" name="Create Import Declaration from GR Document">
      <bpmn:incoming>sf2a</bpmn:incoming>
      <bpmn:outgoing>sf3a</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Duty" name="Calculate Duty (Import Duty Framework — Item Level)">
      <bpmn:incoming>sf3b</bpmn:incoming>
      <bpmn:incoming>sf3a</bpmn:incoming>
      <bpmn:outgoing>sf4</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_File" name="File with Customs Authority (EDI / Broker IDoc)">
      <bpmn:incoming>sf4</bpmn:incoming>
      <bpmn:outgoing>sf5</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Release" name="Receive Release Confirmation">
      <bpmn:incoming>sf5</bpmn:incoming>
      <bpmn:outgoing>sf6</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_MIRO" name="Post Customs Duty in S/4HANA (MIRO — Planned Delivery Cost)">
      <bpmn:incoming>sf6</bpmn:incoming>
      <bpmn:outgoing>sf7</bpmn:outgoing>
    </bpmn:task>

    <bpmn:endEvent id="EE_Import" name="Import Cleared — Duty Posted to FI">
      <bpmn:incoming>sf7</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="sf1" sourceRef="SE_PO" targetRef="GW_Timing"/>
    <bpmn:sequenceFlow id="sf_before" name="Before GR" sourceRef="GW_Timing" targetRef="T_Invoice"/>
    <bpmn:sequenceFlow id="sf_after" name="After GR" sourceRef="GW_Timing" targetRef="T_GR"/>
    <bpmn:sequenceFlow id="sf2b" sourceRef="T_Invoice" targetRef="T_DeclBefore"/>
    <bpmn:sequenceFlow id="sf2a" sourceRef="T_GR" targetRef="T_DeclAfter"/>
    <bpmn:sequenceFlow id="sf3b" sourceRef="T_DeclBefore" targetRef="T_Duty"/>
    <bpmn:sequenceFlow id="sf3a" sourceRef="T_DeclAfter" targetRef="T_Duty"/>
    <bpmn:sequenceFlow id="sf4" sourceRef="T_Duty" targetRef="T_File"/>
    <bpmn:sequenceFlow id="sf5" sourceRef="T_File" targetRef="T_Release"/>
    <bpmn:sequenceFlow id="sf6" sourceRef="T_Release" targetRef="T_MIRO"/>
    <bpmn:sequenceFlow id="sf7" sourceRef="T_MIRO" targetRef="EE_Import"/>
  </bpmn:process>
</bpmn:definitions>

Customs Broker Integration

Large importers typically use customs brokers who operate their own filing systems. GTS supports three integration models for this relationship:

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

    subgraph BrokerCentric["Broker-Centric"]
        BC1["Broker files declaration<br>independently"]
        BC2["IDoc IB001 received<br>in GTS with MRN"]
        BC3["GTS declaration updated<br>with broker data"]
        BC1 --> BC2 --> BC3
    end

    subgraph ImporterCentric["Importer-Centric"]
        IC1["GTS creates initial<br>import declaration"]
        IC2["Outbound service sends<br>declaration to broker"]
        IC3["Broker enriches and files<br>with authority"]
        IC4["Inbound service returns<br>MRN and release status"]
        IC1 --> IC2 --> IC3 --> IC4
    end

    subgraph ExporterCentric["Exporter-Centric"]
        EC1["GTS creates export<br>declaration"]
        EC2["Broker handles<br>physical clearance"]
        EC3["Status callback updates<br>GTS document"]
        EC1 --> EC2 --> EC3
    end

    class BC1,IC1,EC1 source
    class BC2,IC2,IC3,EC2 integration
    class BC3,IC4,EC3 target

The IDoc flow is standard: CUSDEC (outbound) carries the declaration from GTS to the broker’s system; IB001 (inbound) carries the registration number, assessed duties, and release status back. In the importer-centric scenario, GTS acts as the system of record and the broker’s system is the filing agent — the distinction that matters for audit trail purposes, since every assessed duty value and MRN must be traceable back to a GTS customs document.

Preference Certificates: Eliminating the Duty Liability

The Commercial Logic

A preference certificate issued to a customer converts a potential import duty from a cost into a competitive lever. If a manufacturer qualifies its product under a free trade agreement and issues a Long-Term Supplier’s Declaration (LTSD) or blanket certification to its customer, that customer can import at the preferential (often zero) duty rate instead of the MFN rate. The duty savings either flow to the customer as a lower landed cost or are captured by the exporter through a stronger negotiating position.

The key distinction — frequently conflated in practice — is between preferential and non-preferential origin:

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

    subgraph Pref["Preferential Origin"]
        P1["Governed by FTA rules<br>of origin"]
        P2["Purpose: claim reduced<br>or zero import duty"]
        P3["Result: preference<br>statement / certificate"]
        P1 --> P2 --> P3
    end

    subgraph NonPref["Non-Preferential Origin"]
        N1["Governed by importing<br>country's domestic rules"]
        N2["Purpose: anti-dumping,<br>embargoes, quotas"]
        N3["Result: country-of-origin<br>marking on product"]
        N1 --> N2 --> N3
    end

    Note["Two separate determinations<br>— do not conflate"]

    Pref --- Note
    NonPref --- Note

    class P1,P2,P3 target
    class N1,N2,N3 source
    class Note integration

A product can carry a “Made in USA” marking for non-preferential purposes and still fail the USMCA rule of origin for a specific FTA. And a product that qualifies under one agreement does not automatically qualify under another — each is evaluated independently. GTS enforces this separation at the data model level: preferential and non-preferential determination results are stored in distinct structures with distinct validity periods.

Issuing Outbound Preference Certificates

Once preference determination has been run — the process covered in Part 2 — GTS generates outbound preference documents through the Supplier’s Declaration: Outbound application. The choice between a transactional certificate (per shipment) and an LTSD (covering a defined validity period) depends on shipment frequency and the customer relationship.

<?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="PreferenceCert" targetNamespace="http://sajivfrancis.com/gts">
  <bpmn:process id="proc_pref_cert" isExecutable="false" name="GTS Preference Certificate — Outbound LTSD">

    <bpmn:startEvent id="SE_PrefDet" name="Preference Determination Result: Qualifying">
      <bpmn:outgoing>sf1</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:task id="T_Stmt" name="Generate Preference Statement on Billing Document">
      <bpmn:incoming>sf1</bpmn:incoming>
      <bpmn:outgoing>sf2</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="GW_Type" name="Certificate Type?">
      <bpmn:incoming>sf2</bpmn:incoming>
      <bpmn:outgoing>sf3_ltsd</bpmn:outgoing>
      <bpmn:outgoing>sf3_trans</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="T_LTSD" name="Create Outbound LTSD (Manage LTSD — Outbound Entry)">
      <bpmn:incoming>sf3_ltsd</bpmn:incoming>
      <bpmn:outgoing>sf4</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Trans" name="Create Transactional Certificate of Origin">
      <bpmn:incoming>sf3_trans</bpmn:incoming>
      <bpmn:outgoing>sf4b</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Send" name="Send to Customer via PPF Action (PDF / EDI)">
      <bpmn:incoming>sf4</bpmn:incoming>
      <bpmn:incoming>sf4b</bpmn:incoming>
      <bpmn:outgoing>sf5</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="T_Retain" name="Retain Record per Goods Retention Period">
      <bpmn:incoming>sf5</bpmn:incoming>
      <bpmn:outgoing>sf6</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="GW_Change" name="BOM or Supplier Changed?">
      <bpmn:incoming>sf6</bpmn:incoming>
      <bpmn:outgoing>sf7_yes</bpmn:outgoing>
      <bpmn:outgoing>sf7_no</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="T_Reissue" name="Reissue LTSD (Manage Reissue Reasons — Worklist)">
      <bpmn:incoming>sf7_yes</bpmn:incoming>
      <bpmn:outgoing>sf8</bpmn:outgoing>
    </bpmn:task>

    <bpmn:endEvent id="EE_Valid" name="Certificate Valid — Customer Claims Preference">
      <bpmn:incoming>sf7_no</bpmn:incoming>
      <bpmn:incoming>sf8</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="sf1" sourceRef="SE_PrefDet" targetRef="T_Stmt"/>
    <bpmn:sequenceFlow id="sf2" sourceRef="T_Stmt" targetRef="GW_Type"/>
    <bpmn:sequenceFlow id="sf3_ltsd" name="Long-Term" sourceRef="GW_Type" targetRef="T_LTSD"/>
    <bpmn:sequenceFlow id="sf3_trans" name="Transactional" sourceRef="GW_Type" targetRef="T_Trans"/>
    <bpmn:sequenceFlow id="sf4" sourceRef="T_LTSD" targetRef="T_Send"/>
    <bpmn:sequenceFlow id="sf4b" sourceRef="T_Trans" targetRef="T_Send"/>
    <bpmn:sequenceFlow id="sf5" sourceRef="T_Send" targetRef="T_Retain"/>
    <bpmn:sequenceFlow id="sf6" sourceRef="T_Retain" targetRef="GW_Change"/>
    <bpmn:sequenceFlow id="sf7_yes" name="Yes — reissue required" sourceRef="GW_Change" targetRef="T_Reissue"/>
    <bpmn:sequenceFlow id="sf7_no" name="No change" sourceRef="GW_Change" targetRef="EE_Valid"/>
    <bpmn:sequenceFlow id="sf8" sourceRef="T_Reissue" targetRef="EE_Valid"/>
  </bpmn:process>
</bpmn:definitions>

Intercompany LTSD Flow

The intercompany scenario is where the preference certificate chain becomes genuinely complex. A manufacturing entity in Mexico sells to its US affiliate. The US affiliate re-exports to an end customer. For the US entity to issue a preference certificate to its customer, it must first have received a valid LTSD from its Mexican affiliate. GTS handles this through an intercompany LTSD — an outbound LTSD from the manufacturing entity that is automatically received as an inbound LTSD by the selling entity, both modeled as Foreign Trade Organizations in the same GTS system.

The chain: the manufacturing entity runs preference determination and qualifies the product; GTS creates an outbound LTSD from the manufacturer to the selling affiliate; the selling affiliate receives the inbound LTSD and references it in its own outbound LTSD to the end customer; the end customer imports at the preferential duty rate. The system enforces traceability at every link — each outbound certificate is backed by the inbound documentation that justified it.

Certificate Lifecycle and Reissuance Triggers

A certificate issued today can become invalid tomorrow. If a new non-originating component is introduced into the BOM and pushes the de minimis threshold over its limit, every outstanding LTSD that covered the affected product is now incorrect. GTS manages this through the Goods Retention Period configuration and the Reissue Reasons worklist. When a vendor LTSD is updated or a BOM component changes, GTS generates a worklist of affected outbound LTSDs requiring reissuance.

This is not optional maintenance. Issuing an incorrect preference certificate exposes the organization to post-entry audits, duty underpayment penalties, and — in the US context — potential liability under statutes governing customs fraud. The reissuance workflow in GTS is the control that prevents an isolated engineering change from creating a compliance exposure across the customer base.

Reporting and Embedded Analytics

Architecture Layers

GTS Embedded Analytics sits on the HANA platform and exposes data through three layers: the operative GTS transactional tables, HANA CDS and calculation views, and optionally BW/4HANA or SAP Datasphere for enterprise-scale reporting. The architecture is deliberately layered so that operational users get real-time status from Fiori tiles while BI teams consume the same underlying data through their preferred reporting tool without redundant extraction.

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

    subgraph HANA["SAP HANA Platform"]
        Trans["GTS Transactional Tables<br>(Operative Data)"]
        CV["Calculation Views<br>(CDS / Analytic Views)"]
        Trans --> CV
    end

    subgraph EMBEDDED["Embedded Analytics"]
        GTSReport["GTS Standard Reports<br>(Fiori / SAP GUI)"]
        CV --> GTSReport
    end

    subgraph ENTERPRISE["Enterprise Reporting"]
        BW["SAP BW/4HANA<br>(LSA++ Architecture)"]
        DS["SAP Datasphere<br>(Data Fabric)"]
        AC["SAC — Analytics Cloud<br>(Visualization)"]
        CV -->|"HANA replication"| BW
        CV -->|"virtual access"| DS
        BW --> AC
        DS --> AC
    end

    class Trans source
    class CV integration
    class GTSReport target
    class BW,DS,AC reporting

Key Operational Reports

The standard report catalog spans all five functional pillars. In compliance management: Manage Blocked Partners surfaces the SPL screening audit trail; Analyze Reasons for Release logs every release justification; Display Partner in Embargo Countries provides exposure visibility; Display Existing Licenses tracks utilization against validity dates; Manage Blocked Documents provides a unified view of all held customs documents. In customs execution: Display Export Declarations gives declaration status across the export portfolio; Display Import/Export Authorizations tracks authorization consumption. In preference management: Manage LTSDs — Outbound shows every issued certificate and its current validity; Display Worklist: Process/Production Orders drives the preference determination queue; Country Assignment to Agreement maps countries to their applicable preferential arrangements. In product and classification: Display Products (Classified) shows classification coverage across the product catalog.

{
  "data": [
    {
      "type": "bar",
      "name": "Standard Fiori Reports",
      "x": ["Compliance Management", "Customs Export", "Customs Import", "Preference Management", "Product & Classification"],
      "y": [6, 3, 2, 4, 2],
      "marker": {"color": "#1565c0"}
    },
    {
      "type": "bar",
      "name": "SAP GUI / Legacy Reports",
      "x": ["Compliance Management", "Customs Export", "Customs Import", "Preference Management", "Product & Classification"],
      "y": [2, 2, 1, 2, 1],
      "marker": {"color": "#e65100"}
    }
  ],
  "layout": {
    "title": "GTS Standard Reports by Functional Area",
    "barmode": "stack",
    "xaxis": {"title": "Functional Area"},
    "yaxis": {"title": "Number of Standard Reports"},
    "legend": {"orientation": "h", "y": -0.2},
    "plot_bgcolor": "#fafafa",
    "paper_bgcolor": "#ffffff"
  }
}

The migration from SAP GUI-based reporting to Fiori-native tiles is nearly complete in the HANA edition for compliance management, where the operational cadence — daily SPL screening reviews, blocked document resolution — benefits most from the simplified interface. Customs and preference reporting has a longer tail of SAP GUI transactions that remain in use, largely because customs operations staff tend to be power users who know the transaction codes and have workflow routines built around them.

Migration: SAP GTS 11.0 to SAP GTS, Edition for SAP HANA

The Conversion Topology

Organizations running SAP GTS 11.0 — or 10.0 / 10.1 — can convert to SAP GTS, edition for SAP HANA installed on SAP S/4HANA 2022 as the base product. The conversion is executed using the Software Update Manager (SUM) with the Database Migration Option (DMO) if the source system is not already on HANA. Systems on earlier versions must first upgrade to 10.0, 10.1, or 11.0 before attempting the HANA edition conversion — there is no direct path from earlier releases.

The key software component changes from the conversion are: SLL-LEG becomes GTSCORE; SAP_AP is retrofitted into S4CORE. The minimum SUM version required is 2.0 SP16, though the standing practice is to use the latest available patch at the time of execution.

Conversion Phases

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

    P0["Prerequisite Check<br>(Readiness Report)"]
    P1["Custom Code Analysis<br>(Migration Elements)"]
    P2["BAdI Migration<br>(SE18 / SE19)"]
    P3["Maintenance Planner<br>(Stack XML Generation)"]
    P4["SUM Execution<br>(Roadmap Selection)"]
    P5["DB Migration — Optional<br>(DMO to HANA)"]
    P6["Software Installation<br>(HANA Edition Stack)"]
    P7["Data Conversion<br>(XPRA: /SAPSLL/XPRA_V8000)"]
    P8["Custom Transport Import<br>(Post-Conversion Adjustments)"]
    P9["Functional Validation<br>(Smoke Tests + Regression)"]

    P0 --> P1 --> P2 --> P3 --> P4
    P4 --> P5
    P5 --> P6
    P6 --> P7
    P7 --> P8
    P8 --> P9

    class P0,P1,P2,P3 source
    class P4,P5,P6 integration
    class P7,P8,P9 target

Phase	Key Activity	Tool / Transaction	Notes
Prerequisite Check	Run readiness report	`/SAPSLL/READINESS_CHK_V8000`	Surfaces incompatible objects before SUM starts
Custom Code Analysis	Identify custom code affected by API changes	Custom Code Migration (CCM) tool	Establishes transport request scope
BAdI Migration	Migrate classic BAdIs to kernel-based BAdIs	SE18, SE19, IMG	Compatibility-mode BAdIs will be deactivated in follow-on releases
Maintenance Planner	Generate target stack XML for SUM	SAP Maintenance Planner (browser)	Confirms S/4HANA 2022 + GTSCORE combination
SUM Execution	Run upgrade	SUM 2.0 SP16+	System is in downtime during software installation phase
DMO (if needed)	Migrate database to SAP HANA	SUM DMO	Only required if source DB is not HANA
Data Conversion	Automated XPRA execution	`/SAPSLL/XPRA_V8000`	Converts GTS data structures — runs concurrently during upgrade
Custom Transport Import	Import custom code and configuration transports	STMS	All changes, additions, and deletions are in scope
Functional Validation	End-to-end process testing	Manual + automated regression	SPL screening, customs declarations, preference determination

BAdI Migration: The Detail That Breaks Timelines

The BAdI migration step is consistently underestimated because the readiness report surfaces affected objects but says nothing about the business logic inside them. SAP GTS has a substantial catalog of BAdIs that implementations use for custom determination logic, document enrichment, message transformation, and screening extensions. Every active implementation must be inventoried, understood, and re-created before the migration completes.

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

    ClassicBAdI["Classic BAdI<br>(SE18 — Compatibility Mode)"]
    KernelBAdI["Kernel-Based BAdI<br>(New Definition)"]
    Impl["New Implementation<br>(Replicated Logic)"]
    Runtime["Runtime: Only New BAdI<br>Called When Active"]

    ClassicBAdI -->|"create successor"| KernelBAdI
    KernelBAdI -->|"implement via SE19 / IMG"| Impl
    Impl -->|"activate"| Runtime
    ClassicBAdI -->|"deactivated at runtime<br>once successor active"| Runtime

    class ClassicBAdI source
    class KernelBAdI integration
    class Impl,Runtime target

Three rules govern this work. First, inventory every active BAdI implementation before SUM starts — not just the names but the logic, the edge cases, and any feeder system dependencies the BAdI has introduced over time. Second, create the kernel-based successor and replicate the logic — method names and parameters are largely preserved across the interface versions, so this is typically a port rather than a rewrite, but the interface must be verified. Third, activate the new BAdI implementation only after full testing in a non-production environment, because once it is active the classic BAdI is bypassed entirely at runtime with no fallback.

The organizations that hit timeline overruns in GTS migrations almost invariably do so because they scoped BAdI migration as a one-sprint task and discovered, mid-project, that several BAdIs contain multi-year accumulations of business logic that no current team member fully understands.

Migration Effort Distribution

{
  "data": [
    {
      "type": "pie",
      "labels": [
        "Custom Code & BAdI Migration",
        "Functional Testing & Validation",
        "Data Conversion & XPRA",
        "Prerequisite & Readiness",
        "SUM Execution & DB Migration",
        "Transport Management"
      ],
      "values": [35, 30, 12, 10, 8, 5],
      "hole": 0.4,
      "marker": {
        "colors": ["#1565c0", "#2e7d32", "#e65100", "#6a1b9a", "#c62828", "#f57f17"]
      },
      "textinfo": "label+percent"
    }
  ],
  "layout": {
    "title": "Estimated Effort Distribution — GTS 11.0 to HANA Edition Migration (modeled estimate)",
    "annotations": [
      {
        "text": "Effort<br>Split",
        "x": 0.5,
        "y": 0.5,
        "font": {"size": 14},
        "showarrow": false
      }
    ],
    "paper_bgcolor": "#ffffff"
  }
}

Custom code and BAdI migration consumes the largest share of effort at an estimated 35% of total project work, followed by functional testing and validation at approximately 30% (modeled estimate — actual proportions depend heavily on the volume and complexity of custom implementations in the source system). Data conversion via the automated XPRA program is largely non-labor-intensive once the prerequisites are met; it represents process risk more than effort.

Deployment Topology After Migration

GTS, edition for SAP HANA supports the same two deployment models as the classic release, now with native SAP Fiori throughout:

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

    subgraph Embedded["Embedded Deployment"]
        E_S4["S/4HANA System<br>(Contains GTS Core)"]
        E_Fiori["SAP Fiori Launchpad<br>(Embedded)"]
        E_S4 <-->|"in-process"| E_Fiori
    end

    subgraph Hub["Hub Deployment"]
        H_S4["S/4HANA Feeder System<br>(ERP Transactions)"]
        H_GTS["GTS Hub System<br>(Standalone)"]
        H_Fiori["SAP Fiori Launchpad<br>(Hub)"]
        H_S4 -->|"IDocs / RFC"| H_GTS
        H_GTS <-->|"in-process"| H_Fiori
    end

    class E_S4,H_S4 source
    class E_Fiori,H_Fiori integration
    class H_GTS target

The embedded model eliminates the RFC/IDoc hop between the feeder system and GTS — all trade compliance checks run in-process, which reduces latency on screening decisions and simplifies the integration landscape. The hub model remains the correct choice when multiple feeder systems need to route into a single GTS instance, which is the common configuration for large multinationals running regional S/4HANA systems under a single global trade compliance umbrella.

The Full GTS Capability Map

Across all three parts of this series, GTS, edition for SAP HANA covers five functional pillars. The capability map shows how they interlock:

mindmap
  root((SAP GTS<br>HANA Edition))
    Compliance Management
      SPL Screening
      Embargo Checks
      Legal Control
      Re-Export Control
      License Management
    Customs Management
      Export Declarations
      Import Declarations
      Transit Procedures
      Bonded Warehouse
      Inward Processing
      Outward Processing
      Foreign Trade Zones
      EMCS
      Broker Integration
    Preference Management
      Inbound LTSDs
      Preference Determination
      Top-Down Calculation
      Bottom-Up Calculation
      Outbound Certificates
      Intercompany Flow
    Product and Classification
      Tariff Classification
      Legal Control Classification
      PGA Records
      Numbering Schemes
    Analytics and Migration
      Embedded Analytics
      BW and Datasphere
      GTS to HANA Migration
      BAdI Migration
      SUM and DMO

What the Three Parts Cover End-to-End

Topic	Part 1	Part 2	Part 3
Architecture and FTO structure	✓
Feeder system integration	✓
Master data setup	✓
SPL screening and embargo	✓
Legal control and licensing	✓
Export customs declarations		✓	✓ FI integration
Import customs declarations		✓	✓ Duty framework
Special customs procedures		✓
Preference determination		✓
Preference certificates (outbound)			✓
Duty posting to FI-CO			✓
Broker IDoc integration			✓
Embedded analytics			✓
Migration to HANA edition			✓

Conclusion

Three conclusions cut across everything covered in this paper.

The declaration-to-ledger loop is complete but not automatic. GTS calculates duty correctly at the item level, maintains customs exchange rates independently of FI exchange rate types, and tracks declaration status through the full e-filing message sequence. But the duty posting to FI flows through S/4HANA via planned delivery costs — that integration requires deliberate configuration of condition types, GL account assignments, and cost object mapping before the first declaration is filed. Organizations that treat the FI integration as a go-live cleanup item will find themselves with a growing backlog of manually journaled duty liabilities and no audit trail connecting them to specific declaration items.

Preference certificates are a living document, not a one-time event. A certificate issued today becomes a liability tomorrow if the underlying BOM changes. GTS manages the reissuance lifecycle through the Goods Retention Period, reissue-reason worklists, and intercompany LTSD chaining — but only if preference determination is run regularly and the change management processes in engineering and procurement are connected to the GTS reissuance workflow. The compliance risk from an issued-but-now-incorrect certificate is not theoretical: customs authorities in the EU, US, and most APAC jurisdictions have active post-entry audit programs that specifically target preferential origin claims. The reissuance trigger in GTS is only as good as the change notification that reaches it.

The migration to the HANA edition is a custom code audit first and a technical upgrade second. The SUM/DMO execution is well-documented and largely predictable once the prerequisites are met. What breaks timelines is the BAdI inventory: classic BAdIs running in compatibility mode will be deactivated in a follow-on release, so the migration window is the forcing function to clear that technical debt. Run /SAPSLL/READINESS_CHK_V8000 early, inventory every active BAdI implementation and the business logic it encodes, and size the transport scope before committing to a go-live date. Organizations that treat the BAdI migration as a technical formality and discover mid-project that key determination logic lives only inside compatibility-mode BAdIs will not make their planned go-live. Those that treat it as a business-logic audit — an opportunity to document, rationalize, and re-implement with current requirements in mind — come out of the migration with a cleaner, more maintainable system than the one they started with.