SAP Global Trade Services — Part 1: Architecture, Integration & the Compliance Backbone

Cross-border trade is operationally expensive by default. The average international transaction touches twenty to thirty departments, forty documents, and two hundred data elements — the majority of which are rekeyed at least once. SAP Global Trade Services (SAP GTS), Edition for SAP HANA, exists to eliminate that rekeying, enforce compliance before a document can proceed, and connect the operational trade execution layer to financial accounting in a way that the core ERP cannot do natively.

This paper — the first in a three-part series — establishes the architectural and integration foundations that every subsequent configuration decision rests on. It covers the hub deployment model, the feeder system integration stack, the organisational structure that drives legal regulation determination, the three compliance engines that block the order-to-cash chain, the classification dependency that governs every cross-border movement, and the financial accounting consequences that flow downstream. Parts 2 and 3 build directly on this foundation: customs management and special procedures in Part 2, preference management, analytics, and the financial close loop in Part 3.

This series walks through SAP GTS, Edition for SAP HANA as a progressive build across three parts:

• Part 1 (this article): System architecture, feeder system integration, the OTC compliance chain, and why GTS operates as a hub — not a bolt-on
• Part 2: Customs Management in depth — import and export declarations, special procedures (bonded warehouse, inward processing relief, outward processing relief, free trade zones), and electronic communication with customs authorities
• Part 3: Preference Management, trade analytics, migration from GTS 11.0, and the financial accounting close loop — where GTS data flows into FI-CO

SAP S/4HANA handles logistics and financials with depth. What it does not handle natively — at the scale multinationals require — is the full compliance surface of international trade:

• Screening every transacting party against sanctioned party lists across dozens of jurisdictions, in real time, at the point of document save
• Blocking shipments to embargoed destinations before the sales order can be completed
• Managing export licenses with quantity and value drawdown across document chains
• Tracking duty-suspended inventory inside bonded warehouses or inward processing regimes
• Filing electronic customs declarations directly to national customs authorities or through conversion providers

These are not edge-case requirements. They are baseline operational obligations for any company moving goods across borders at scale. SAP GTS addresses each one. The defining architectural characteristic is that the compliance block is upstream — it prevents the next document from being created, not flags a problem after the fact. That distinction determines how the entire integration is designed.

SAP GTS (technical component: GTSCORE) operates as a central compliance hub to which feeder systems — the transactional sources that generate business documents — connect. The plug-in installed on the S/4HANA instance handles the connection transparently: when a user saves a qualifying document, the plug-in calls GTS via RFC, GTS runs its checks, and the result either releases or blocks the document before the S/4HANA save completes.

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 FEEDERS["Feeder Systems"]
        S4["SAP S/4HANA<br>(Core ERP)"]
        TM["Embedded TM<br>(Transportation Mgmt)"]
        EWM["Embedded EWM<br>(Warehouse Mgmt)"]
        MDG["SAP MDG<br>(Master Data Gov.)"]
    end

    subgraph PLUGIN["Integration Layer"]
        PI["S/4HANA Plug-In<br>(S4CORE built-in)"]
        WS["Web Services<br>(12 SOA endpoints)"]
        RFC["RFC Connections<br>(SM59)"]
        ASR["Advanced Shipping<br>& Receiving (ASR)"]
    end

    subgraph GTS_HUB["SAP GTS Hub (GTSCORE)"]
        CM["Compliance<br>Management"]
        CUS["Customs<br>Management"]
        PM["Preference<br>Management"]
        CL["Classification<br>Engine"]
    end

    subgraph AUTHORITIES["External Connections"]
        CP["Conversion Provider<br>(e.g. SEEBURGER)"]
        CA["Customs Authorities<br>(ATLAS / AES / NCTS)"]
        SPL_P["SPL Content<br>Providers"]
    end

    subgraph ANALYTICS["Analytics & Reporting"]
        BW["SAP BW/4HANA"]
        DS["SAP Datasphere"]
        EA["Embedded Analytics<br>(Fiori)"]
    end

    S4 --> PI
    MDG --> PI
    TM --> WS
    EWM --> RFC
    TM & EWM --> ASR

    PI --> GTS_HUB
    WS --> CM
    WS --> CUS
    RFC --> CUS
    ASR --> GTS_HUB

    GTS_HUB --> CP --> CA
    SPL_P --> CM

    GTS_HUB --> BW
    GTS_HUB --> DS
    GTS_HUB --> EA

    class S4,MDG source
    class PI,WS,RFC,ASR integration
    class GTS_HUB,CM,CUS,PM,CL target
    class BW,DS,EA reporting

Two deployment topologies are available:

Hub deployment is the leading practice for large-scale implementations. The GTS legal update cadence is driven by regulatory changes across jurisdictions — this is fundamentally decoupled from the S/4HANA innovation cycle, and keeping them on separate instances preserves that independence. Co-deployment will reduce total cost of ownership but aligns downtime windows: an upgrade to one system affects the other.

Before any compliance logic can execute, two prerequisites must hold: master data must exist in GTS, and the document transfer infrastructure must be active. Both require deliberate configuration.

Master data flows from feeder to GTS — not the reverse, with narrow exceptions such as commodity codes transferred back for Intrastat filing:

Change pointers in S/4HANA ensure that updates to business partner addresses — a critical SPL screening trigger — retransfer automatically via RFC. The initial full-transfer run executes via /SAPSLL/MENU_LEGALR3.

Each application level within S/4HANA maps to a document category and a GTS service:

If master data for a material or business partner does not exist in GTS at the moment of document transfer, the customs document enters a technically incomplete status — a silent failure that blocks downstream processing and requires manual retransfer after the data gap is resolved. This is the single most common root cause of unexplained GTS blocks in go-live environments.

GTS maintains its own organisational hierarchy that maps onto the S/4HANA org structure but carries trade-specific semantics. The mapping is not automatic and must be configured deliberately.

flowchart TD
    classDef business fill:#fff3b0,stroke:#cc9a06
    classDef application fill:#b8d4f0,stroke:#1565c0
    classDef technology fill:#c5e8c5,stroke:#2e7d32

    subgraph S4_ORG["S/4HANA Org Structure"]
        CC["Company Code"]
        PL["Plant"]
        SL["Storage Location"]
    end

    subgraph GTS_ORG["GTS Org Structure"]
        FTO["Foreign Trade Org<br>(FTO)<br>Role: SLLFTO"]
        LU["Legal Unit<br>(LU)<br>Role: SLLSIT"]
        AU["Administrative Unit<br>(AU)<br>Role: SLLMGR"]
        CID["Customs ID<br>(Plant + Storage Loc.)"]
    end

    CC -->|"1:1 leading practice"| FTO
    PL -->|"many:1"| LU
    SL -->|"combined with plant"| CID
    FTO -->|"drives legal regulation<br>by country"| LU
    LU -->|"used in<br>Preference Mgmt"| AU
    CID -->|"authorised reporting unit<br>for special procedures"| LU

    class FTO,LU,AU,CID business
    class CC,PL,SL application

Three constraints govern this mapping and must be treated as hard rules, not guidelines:

1. One company code per FTO — two company codes with different tax IDs cannot share an FTO without producing incorrect legal regulation determination
2. One country per FTO — the FTO country drives customs legal regulation; cross-country company codes require separate FTOs
3. One country per LU — the LU country drives compliance and preference legal regulation; cross-country plants require separate LUs

Violating these constraints does not fail at setup. The failure surfaces at transaction time as incorrect regulation determination — which is significantly harder to diagnose than a configuration error caught during system build.

The order-to-cash process has six natural GTS touchpoints. Each is a potential compliance block that halts downstream document creation until resolved in GTS. The blocks are synchronous with the feeder document save event: the S/4HANA user sees the result immediately; the compliance team sees the blocked document in GTS simultaneously. Neither side can proceed independently.

<?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="otc_gts_compliance"
                  targetNamespace="http://gts.series.part1">

  <bpmn:process id="OTC_GTS_Process" isExecutable="false">

    <bpmn:startEvent id="start" name="Customer Enquiry Received">
      <bpmn:outgoing>flow_start_quotation</bpmn:outgoing>
    </bpmn:startEvent>

    <bpmn:task id="quotation" name="Create Quotation (SD0A)">
      <bpmn:incoming>flow_start_quotation</bpmn:incoming>
      <bpmn:outgoing>flow_quotation_spl</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="spl_check" name="GTS: SPL + Embargo Screen">
      <bpmn:incoming>flow_quotation_spl</bpmn:incoming>
      <bpmn:outgoing>flow_spl_gw</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="gw_spl" name="Compliance Result?">
      <bpmn:incoming>flow_spl_gw</bpmn:incoming>
      <bpmn:outgoing>flow_spl_blocked</bpmn:outgoing>
      <bpmn:outgoing>flow_spl_clear</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="resolve_spl" name="Trade Compliance: Review and Release or Confirm Block">
      <bpmn:incoming>flow_spl_blocked</bpmn:incoming>
      <bpmn:outgoing>flow_resolve_back</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="sales_order" name="Create Sales Order (SD0A)">
      <bpmn:incoming>flow_spl_clear</bpmn:incoming>
      <bpmn:incoming>flow_resolve_back</bpmn:incoming>
      <bpmn:outgoing>flow_so_legalctl</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="legal_control" name="GTS: Legal Control Check (BOM Explosion)">
      <bpmn:incoming>flow_so_legalctl</bpmn:incoming>
      <bpmn:outgoing>flow_lc_gw</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="gw_lc" name="License Available?">
      <bpmn:incoming>flow_lc_gw</bpmn:incoming>
      <bpmn:outgoing>flow_lc_blocked</bpmn:outgoing>
      <bpmn:outgoing>flow_lc_clear</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="resolve_license" name="Apply for and Maintain Export License in GTS">
      <bpmn:incoming>flow_lc_blocked</bpmn:incoming>
      <bpmn:outgoing>flow_license_back</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="outbound_delivery" name="Create Outbound Delivery (SD0B)">
      <bpmn:incoming>flow_lc_clear</bpmn:incoming>
      <bpmn:incoming>flow_license_back</bpmn:incoming>
      <bpmn:outgoing>flow_del_recheck</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="delivery_recheck" name="GTS: Recheck Compliance on Delivery">
      <bpmn:incoming>flow_del_recheck</bpmn:incoming>
      <bpmn:outgoing>flow_proforma</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="proforma" name="Create Pro Forma Invoice (SD0C)">
      <bpmn:incoming>flow_proforma</bpmn:incoming>
      <bpmn:outgoing>flow_pf_exportdec</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="export_declaration" name="GTS: Generate Export Declaration">
      <bpmn:incoming>flow_pf_exportdec</bpmn:incoming>
      <bpmn:outgoing>flow_ed_authorities</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="customs_auth" name="GTS: E-File to Customs Authorities (IDoc/EDI)">
      <bpmn:incoming>flow_ed_authorities</bpmn:incoming>
      <bpmn:outgoing>flow_auth_gw</bpmn:outgoing>
    </bpmn:task>

    <bpmn:exclusiveGateway id="gw_customs" name="Customs Approved?">
      <bpmn:incoming>flow_auth_gw</bpmn:incoming>
      <bpmn:outgoing>flow_customs_rejected</bpmn:outgoing>
      <bpmn:outgoing>flow_customs_approved</bpmn:outgoing>
    </bpmn:exclusiveGateway>

    <bpmn:task id="remediate" name="Remediate Incompleteness and Resubmit">
      <bpmn:incoming>flow_customs_rejected</bpmn:incoming>
      <bpmn:outgoing>flow_remediate_back</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="goods_issue" name="Post Goods Issue and Print EAD">
      <bpmn:incoming>flow_customs_approved</bpmn:incoming>
      <bpmn:incoming>flow_remediate_back</bpmn:incoming>
      <bpmn:outgoing>flow_gi_billing</bpmn:outgoing>
    </bpmn:task>

    <bpmn:task id="billing" name="Create Commercial Invoice (FI Document)">
      <bpmn:incoming>flow_gi_billing</bpmn:incoming>
      <bpmn:outgoing>flow_end</bpmn:outgoing>
    </bpmn:task>

    <bpmn:endEvent id="end" name="Revenue Recognised / GTS Export Closed">
      <bpmn:incoming>flow_end</bpmn:incoming>
    </bpmn:endEvent>

    <bpmn:sequenceFlow id="flow_start_quotation" sourceRef="start" targetRef="quotation"/>
    <bpmn:sequenceFlow id="flow_quotation_spl" sourceRef="quotation" targetRef="spl_check"/>
    <bpmn:sequenceFlow id="flow_spl_gw" sourceRef="spl_check" targetRef="gw_spl"/>
    <bpmn:sequenceFlow id="flow_spl_blocked" name="Blocked" sourceRef="gw_spl" targetRef="resolve_spl"/>
    <bpmn:sequenceFlow id="flow_spl_clear" name="Clear" sourceRef="gw_spl" targetRef="sales_order"/>
    <bpmn:sequenceFlow id="flow_resolve_back" sourceRef="resolve_spl" targetRef="sales_order"/>
    <bpmn:sequenceFlow id="flow_so_legalctl" sourceRef="sales_order" targetRef="legal_control"/>
    <bpmn:sequenceFlow id="flow_lc_gw" sourceRef="legal_control" targetRef="gw_lc"/>
    <bpmn:sequenceFlow id="flow_lc_blocked" name="License Missing" sourceRef="gw_lc" targetRef="resolve_license"/>
    <bpmn:sequenceFlow id="flow_lc_clear" name="License Matched" sourceRef="gw_lc" targetRef="outbound_delivery"/>
    <bpmn:sequenceFlow id="flow_license_back" sourceRef="resolve_license" targetRef="outbound_delivery"/>
    <bpmn:sequenceFlow id="flow_del_recheck" sourceRef="outbound_delivery" targetRef="delivery_recheck"/>
    <bpmn:sequenceFlow id="flow_proforma" sourceRef="delivery_recheck" targetRef="proforma"/>
    <bpmn:sequenceFlow id="flow_pf_exportdec" sourceRef="proforma" targetRef="export_declaration"/>
    <bpmn:sequenceFlow id="flow_ed_authorities" sourceRef="export_declaration" targetRef="customs_auth"/>
    <bpmn:sequenceFlow id="flow_auth_gw" sourceRef="customs_auth" targetRef="gw_customs"/>
    <bpmn:sequenceFlow id="flow_customs_rejected" name="Rejected / Incomplete" sourceRef="gw_customs" targetRef="remediate"/>
    <bpmn:sequenceFlow id="flow_customs_approved" name="MRN Received" sourceRef="gw_customs" targetRef="goods_issue"/>
    <bpmn:sequenceFlow id="flow_remediate_back" sourceRef="remediate" targetRef="goods_issue"/>
    <bpmn:sequenceFlow id="flow_gi_billing" sourceRef="goods_issue" targetRef="billing"/>
    <bpmn:sequenceFlow id="flow_end" sourceRef="billing" targetRef="end"/>

  </bpmn:process>
</bpmn:definitions>

Each compliance function addresses a different risk vector. They operate in sequence on every qualifying document, and each carries distinct configuration logic.

SPL screening checks every business partner on the document — sold-to, ship-to, payer, freight forwarder, bank — against government-issued denied party lists. Two algorithms are available:

• SAP GTS Search — highly configurable; supports delimiters, alias terms, excluded texts, and configurable comparison procedures; the “word-in-word” constraint requires a full name match within the list entry
• SAP HANA Search — simpler configuration; supports hits on name-only or address-only elements (not supported in GTS Search); better performance at scale; requires HANA as the underlying database

For initial bulk master data transfer, asynchronous screening is appropriate. For ongoing operations, synchronous screening via the change pointer mechanism ensures that every new or modified business partner record is screened before it can participate in a transaction.

Embargo operates on the country of the business partner — not the material. If a partner’s country appears on the GTS embargo master, the document is blocked regardless of what is being sold. Product-level destination controls require the legal control function; embargo alone is country-level.

Legal control is the most sophisticated of the three engines. The determination logic runs as follows:

1. Identify active legal regulations for the departure and destination country combination
2. Run the determination strategy to identify applicable license types for the product’s control class (ECCN, USML, or ML classification)
3. Search the GTS license master for a license with matching attributes — FTO, LU, country, control class, product, and available value or quantity headroom
4. Assign the license, decrement value and quantity, and release the document

BOM explosion extends this to finished goods containing controlled components. When a finished product contains ITAR-classified components, GTS explodes the BOM and checks each component independently, generating the correct license requirement against the finished goods sales order.

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

    DOC["Sales Order Item<br>(feeder system)"]
    LR["Legal Regulation<br>Determination<br>(departure × destination)"]
    DS["Determination Strategy<br>(country × control class)"]
    LT["License Type<br>Candidates"]
    LM["License Master<br>Attribute Match"]
    DG["Depreciation Group<br>Value/Qty Drawdown"]
    REL["Document Released"]
    BLK["Document Blocked<br>→ apply for license"]
    BOM["BOM Explosion<br>(for finished goods)"]

    DOC --> LR
    DOC --> BOM
    BOM --> LR
    LR --> DS
    DS --> LT
    LT --> LM
    LM -->|"All attributes match"| DG
    LM -->|"No match or<br>insufficient headroom"| BLK
    DG --> REL

    class DOC source
    class LR,DS,LT integration
    class LM,DG target
    class REL,BLK,BOM reporting

Cross-border transactions expose the most consequential GTS configuration dependency: classification must precede the transaction. Every product crossing a border requires a complete classification profile before the customs document can be e-filed.

If a product is unclassified when the customs document is created, the declaration is incomplete and cannot be transmitted. The incompleteness check — configurable per message type and per country — enforces this at transmission, not at order entry. That timing matters: an order can be created and processed through picking and packing before the incompleteness surfaces at the transmission gate.

The customs value calculation underpins duty determination at the item level. A representative import follows a structured duty framework — transaction value plus transport and insurance costs establishes the customs value base, to which the applicable third-country duty rate is applied, generating the duty liability that then becomes the VAT base for import VAT:

{
  "data": [
    {
      "type": "waterfall",
      "x": ["Transaction Value", "Transport Costs", "Insurance Costs", "= Customs Value", "Third-Country Duty (3.2%)", "= Total Duty", "VAT Base", "VAT (21%)"],
      "y": [350.00, 3.50, 1.25, 0, 11.35, 0, 0, 76.88],
      "measure": ["relative", "relative", "relative", "total", "relative", "total", "total", "relative"],
      "text": ["€350.00", "+€3.50", "+€1.25", "€354.75", "+€11.35", "€11.35", "€366.10", "+€76.88"],
      "textposition": "outside",
      "connector": {"line": {"color": "#1565c0"}},
      "increasing": {"marker": {"color": "#2e7d32"}},
      "totals": {"marker": {"color": "#1565c0"}}
    }
  ],
  "layout": {
    "title": "Import Duty Framework — Sample Calculation (modelled estimate)",
    "yaxis": {"title": "EUR (€)", "tickprefix": "€"},
    "xaxis": {"title": "Duty Component"},
    "showlegend": false,
    "plot_bgcolor": "#f9f9f9"
  }
}

This calculation — executed in GTS at the item level and distributable across the shipment by weight or value — generates the landed cost basis that flows into FI-CO as part of goods receipt valuation. That connection is the first concrete link between GTS and financial accounting, and it is covered in full in Part 3.

Five distinct integration mechanisms operate across a GTS landscape. Understanding which mechanism carries which data type — and in which direction — is essential for both initial setup and ongoing support:

The conversion provider layer — typically a middleware product such as SEEBURGER — is the external-facing boundary. It translates GTS IDocs into country-specific authority formats: ATLAS for Germany, AES for the United States, NCTS for EU transit. This is the bridge between SAP’s internal document model and the heterogeneous national customs systems that receive the declarations.

The Advanced Shipping and Receiving (ASR) integration represents the most recent architectural simplification. It consolidates Transportation Management, Embedded EWM, and GTS communication around a single business object — the freight order — eliminating the need for separate transportation units in embedded EWM and enabling customs invoice creation directly from TM. As of the current release, ASR does not yet fully support package building or delivery splits; those scenarios continue to require the conventional RFC path.

SAP GTS, Edition for HANA replaces the SAP GUI navigation with a Fiori launchpad organised by spaces, pages, sections, and tiles. The business role assigned to a user determines what they see and what they can act on:

Activation runs via Transaction STC01 in two task sequences: SAP_FIORI_FOUNDATION_S4 for the foundation layer, followed by SAP_FIORI_CONTENT_ACTIVATION for role-based app activation. Administrative functions — archiving, background processing, default data configuration — remain in SAP GUI under the /SAPSLL/GTS_ADMINISTRATOR role and are not surfaced in the Fiori launchpad.

GTS sits between the operational and financial layers in a way that is easy to underestimate. Two consequences are immediate and direct.

First, the export declaration closure is a prerequisite for VAT zero-rating proof. When goods leave an EU customs territory, the exit confirmation — an I-message received from the office of exit and recorded in GTS — is the document that substantiates VAT-exempt treatment on the commercial invoice in FI. Without a closed export declaration in GTS, the VAT exemption is unsupported.

Second, the import duty calculation in GTS becomes the landed cost basis in FI-CO. Duty calculated at the item level, distributed across the shipment, flows into goods receipt valuation and cost center or profit center allocation. What GTS records as a customs liability, FI records as a posting.

These two connections become the structural throughline for the remainder of the series:

• Part 2 examines special customs procedures — bonded warehouse, inward processing relief, outward processing relief, and free trade zones — where duty-suspended inventory creates a parallel stock accounting track in GTS that must reconcile with S/4HANA inventory values. Closing portions, scrapping events, and stock corrections each propagate through both systems, and the sequencing is non-trivial.
• Part 3 closes the loop entirely: preference management determines FTA eligibility and the duty cost reduction that flows from it; GTS reporting feeds SAP BW/4HANA and Datasphere for trade analytics; and the migration path from GTS 11.0 to Edition for HANA is mapped with its simplification list implications for existing FI-CO configurations.

The architecture established here — hub deployment, org structure mapping, the OTC compliance chain, the classification dependency, the five-mechanism integration stack — is the foundation every Part 2 and Part 3 configuration decision rests on. Nothing in the subsequent parts can be understood cleanly without the design choices made at this layer.

For organisations implementing SAP GTS or evaluating an upgrade to Edition for HANA, this analysis points to five decisions that must be made early and made correctly — because all of them are difficult to reverse once transactional data has accumulated:

1. Deployment topology — commit to hub or co-deployment based on upgrade cycle independence requirements, not TCO alone. Hub deployment protects the GTS legal update cadence; co-deployment trades that independence for lower infrastructure cost.

2. Organisational structure mapping — validate the one-company-code-per-FTO and one-country-per-LU constraints against the actual legal entity and plant structure before any configuration begins. Discovering a violation after transactional data exists means reconfiguration under live conditions.

3. Master data classification completeness — establish a classification completeness target (commodity codes, control classes, preferential origin data) before go-live. The incompleteness check will not surface unclassified products until the transmission gate; that is too late.

4. Integration mechanism selection for TM and EWM — decide early whether ASR or conventional RFC will carry the TM and EWM document flows. ASR simplifies the architecture but carries functional gaps in package building and delivery splits at the current release; know which scenarios apply before committing.

5. Compliance engine sequencing and activation — SPL, embargo, and legal control are independent activation decisions. Organisations that activate all three simultaneously for the first time on a live system will face a volume of blocks that the compliance team cannot clear at go-live pace. A phased activation strategy — SPL first, embargo second, legal control third — is the lower-risk path.

Each of these decisions connects forward: the org structure drives preference management in Part 3, the classification strategy drives customs special procedure accounting in Part 2, and the integration mechanism selection determines what data is available for trade analytics reporting. Getting them right at the foundation layer is the condition under which the rest of the implementation succeeds.

→ Next: Part 2 — Customs Management in Depth: Declarations, Special Procedures, and Electronic Communication with Authorities