What integration actually touches
A working TSS integration for a forwarder touches four systems: the client onboarding record, the product master, the operational booking system, and the finance ledger that tracks payment routing per client.
Client onboarding record
Onboarding produces the signed data specification, EORI, UKIMS position, and commercial terms. These become configuration inputs to every downstream module.
Product master per client
Products belong to clients. Sharing a global master across traders is where data cross-contamination begins. This Northern Ireland customs software walkthrough lists hard client data separation as the first of six multi-client software requirements.
Booking system as the trigger
The booking triggers the declaration, not the other way round. Movement references cannot be built until customs data exists, so the booking system needs the declaration status back on the same record.
Finance ledger and payment routing
TSS lets agents facilitate payments. Finance needs visible routing per client per declaration, so month-end reconciles without spreadsheet archaeology.
API vs portal, per lane
Repeat lanes go to the API. Ad-hoc, new-client, or unusual movements go to the portal. Integration design accepts the mix rather than forcing a single channel.
Retention and offboarding
Data retention arrangements when a client departs are a contract question that the integration must honour. Build the export path before it's needed.
See a full-stack TSS integration walkthrough. Watch a demo.
Top comments (0)