CUSCAR Customs Cargo Reports and Advance Manifest Timing

An ocean carrier's integration team spends a quarter building one UN/EDIFACT CUSCAR feed, on the reasonable assumption that a United Nations customs message will satisfy customs everywhere. Testing against the US fails on day one, because CBP's vessel manifest system does not take CUSCAR at all. India fails next: ICEGATE wants a digitally signed JSON file named to a fixed pattern, and returns a structural failure for a four-character field the carrier filled with twelve.

A CUSCAR message is still the right way to model a customs cargo report, because its segment groups mirror how a manifest is built: voyage, equipment, consignment, goods. The fix is to treat CUSCAR as one output of an internal manifest record, not the record itself, and to map each customs authority's format and filing clock separately. This guide explains the segment structure, message functions and responses, where the US accepts CUSCAR and where it wants X12 or CAMIR, India's SCMTR arrival manifest, a field mapping, and a rollout checklist.

• Who this is for: EDI and integration analysts and IT leads at carriers, NVOCCs, 3PLs and shippers who build or buy customs manifest interfaces.
• What it adds: an annotated CUSCAR sample, a CUSCAR-to-ICEGATE field map, the US and Indian filing clocks side by side, a rejected-manifest trace and a gateway checklist.

What a CUSCAR message reports, and who transmits it

CUSCAR is the UN/EDIFACT customs cargo report: a carrier, or someone filing for it, tells a customs administration what cargo a conveyance is carrying. CBP's own implementation guide describes the message as letting a carrier transfer data to a customs administration to meet cargo reporting requirements. National guides then restrict which segments, qualifiers and code values are allowed.

Two published guides show how much those restrictions vary. The South African Revenue Service guide, version 1 variant 3 dated October 2017, is based on directory D.16B and uses one CUSCAR for container master and house bills, bulk cargo, empty container lists, air waybills, rail consignment notes and road manifests, told apart by a document type in BGM. CBP's truck guides are narrower and serve only the truck manifest.

Reading the segment groups: TDT, EQD, CNI and GID

Read a CUSCAR from the outside in: the transport means, then the boxes on it, then each bill of lading, then the goods under each bill. The groups below use the layout in the SARS D.16B guide, which numbers transport as group 4, equipment as group 5, consignment as group 7 and goods items as group 14. Other directories and national guides renumber or trim groups, so always map against the guide the receiving authority publishes.

UNH+1+CUSCAR:D:16B:UN'
BGM+85:::COM+MNF2611041+9'           85 = customs manifest, COM = container master, 9 = original
DTM+137:202611081410:203'            document date and time
TDT+20+118W+1'                       main carriage, voyage 118W, mode 1 = maritime
LOC+9+LKCMB'                         place of loading
LOC+11+INNSA1'                       place of discharge
DTM+132:202611111800:203'            estimated arrival
EQD+CN+MSKU1234565'                  container, ISO 6346 check digit 5
MEA+AAE+G+KGM:24850'                 gross mass of the container
SEL+SL0098812+CA'                    carrier seal
CNI+1+MAEU611204871'                 consignment 1, bill of lading number
RFF+BM:MAEU611204871'
NAD+CN+++NORTHFIELD PUMPS PVT LTD'   consignee
GID+1+1200:CT'                       goods item 1, 1,200 cartons
FTX+AAA+++CENTRIFUGAL PUMP SPARES'   goods description
MEA+AAE+G+KGM:18400'
SGP+MSKU1234565+1200'                split goods placement: cartons in this box
UNT+18+1'

Illustrative only: qualifiers, codes and mandatory segments come from the
receiving authority's implementation guide, not from this sample.

The SGP segment is the one integrations most often drop. It ties a goods item to the container it sits in, and without it customs cannot tell which box to examine when a consignment spreads across several containers. SARS marks SGP as required for containerised cargo. The same logic explains why the EQD group carries both gross mass and seals: those are the two facts an examination officer checks first at the box.

A CUSCAR customs cargo report built on UN/EDIFACT directory D.16B, as in the South African Revenue Service guide, nests transport in segment group 4, equipment in group 5, consignments in group 7 and goods items in group 14, and every containerised goods item needs one SGP segment per container holding it.

• Document type in BGM: the SARS guide uses BGM 1001 code 85 for a customs manifest and a separate document name such as COM, COH or BBB for master, house and bulk filings.
• Party roles in NAD: consignor, consignee and notify parties sit under each consignment, not at message level, because each bill can name different parties.
• Dangerous goods in DGS: hazard data belongs to the goods item, so a mixed bill can declare one hazardous line without flagging the whole consignment.

Original, change and cancel: message functions and replies

Every filing states whether it is new, a change or a cancellation, and an authority will reject a change to something it never accepted. In the SARS guide, BGM data element 1225 takes 9 for an original, 4 for a change and 1 for a cancellation, and its business rules require a document to be accepted before it is amended or cancelled.

Replies come back as CUSRES, the customs response message. CBP publishes a standard truck CUSRES guide used to report acceptance or rejection of a CUSCAR, CUSREP or PAXLST, so the gateway must correlate each CUSRES with the document number and message reference it answers. Without that correlation, a rejection can sit in a mailbox while the operations team assumes the manifest is filed.

Where ACE takes CUSCAR, and where it wants X12 or CAMIR

In the United States, CUSCAR is accepted for truck manifests only. CBP's ACE import manifest documentation lists a Standard Truck Manifest CUSCAR Cargo Report Message and a FAST Truck Manifest CUSCAR guide, alongside CUSRES, CUSREP and PAXLST, all under truck. The ocean section lists CAMIR and ANSI X12 transactions, such as the 309 manifest with security filing and the 350 status message; air lists CAMIR; rail lists X12.

An ocean carrier that holds its manifest as CUSCAR must therefore translate to X12 309 or CAMIR before it can meet the US 24-hour rule. That translation is where data is lost: a CUSCAR goods item linked to several containers through repeated SGP segments has to be re-expressed in the target format's own structure, and a converter written for one-container bills will silently drop the second box.

US Customs and Border Protection accepts UN/EDIFACT CUSCAR in ACE only for truck manifests, under the standard and FAST truck implementation guides; vessel cargo declarations due 24 hours before lading under 19 CFR 4.7(b)(2) must travel as CAMIR or ANSI X12 309, so ocean gateways need a tested translation layer.

US filing clocks: 24 hours before lading, and up to an hour for trucks

The US measures the ocean deadline from loading at the foreign port, not from arrival. Under 19 CFR 4.7(b)(2), CBP must receive the electronic cargo declaration, the equivalent of CBP Form 1302, 24 hours before the cargo is laden aboard the vessel at the foreign port, through AMS or another CBP-approved electronic system.

• NVOCC direct filing: section 4.7(b)(3)(i) lets an NVOCC licensed or registered with the Federal Maritime Commission, holding an international carrier bond, file its own house-level data directly, still 24 hours before lading.
• Bulk cargo: section 4.7(b)(4) exempts bulk cargo from the pre-lading clock and requires the filing 24 hours before arrival instead; break-bulk carriers need a written exemption from CBP's National Targeting Center.
• Truck cargo: 19 CFR 123.92 requires electronic cargo information no later than 30 minutes or one hour before the truck reaches the first US port, depending on the CBP-approved system used.

For a truck filer, that short window is why CUSCAR's response handling matters: a CUSRES rejection received forty minutes before the border leaves little time to correct and resend. For an ocean filer, the 24-hour clock runs at the origin terminal, so the gateway must transmit on receipt of final shipping instructions, not on vessel departure.

India's SCMTR arrival manifest is signed JSON, not EDIFACT

India does not take CUSCAR for sea manifests. Under the Sea Cargo Manifest and Transhipment Regulations, 2018, carriers file the Sea Arrival Manifest, or SAM, through ICEGATE as a JSON declaration defined in the CBIC message implementation guide. The guide names the message SACHM23 and gives file names in a fixed pattern such as F_SACHM23_SAM_ICEGATEID_34556_20200125_DEC.json.

The legal clock comes from section 30 of the Customs Act, 1962, which requires the person in charge of a vessel or aircraft to deliver the arrival manifest electronically before arrival, and allows a penalty of up to ₹50,000 if delay is not explained by sufficient cause. The ICEGATE guide adds that the authorised sea carrier or agent files the arrival manifest before the vessel departs its last port of call for the Indian port.

• Two-level validation: ICEGATE first checks the file against the JSON schema and returns a structural failure file, ending _SFL.json, on any mismatch; only then does business validation run and return an _ACK.json.
• Digital signature: the declaration must be digitally signed, and the guide lists SMTP and web upload as the submission routes.
• Message family: SAM is followed by SAA for amendments and SEI for entry inwards, while departures use SDM, SDA and SDN.
• Current rollout: Jawaharlal Nehru Custom House Public Notice 80/2026 records that all SCMTR messages except import transhipment were fully operational from 1 July 2026, with transitional provisions then extended to 31 August 2026. Notification 90/2026-Customs (N.T.), in force from 1 November 2026, now extends the same transitional entry to 31 January 2027.

Mapping one manifest record to CUSCAR, ACE and ICEGATE

Hold one internal manifest record per voyage and generate each customs format from it, so that a corrected weight changes once and flows everywhere. The table maps the main fields across the three targets. ICEGATE names are the JSON object groups listed in the SCMTR guide; the US column names the target only, because CBP's X12 and CAMIR guides each define their own record layouts.

Field lengths are the commonest silent failure. The SCMTR guide's own structural-failure example rejects a consolidated-cargo indicator because the sender wrote eleven characters into a field allowed four. A gateway should validate every outbound file against the receiving schema before transmission, so that length and pattern errors surface at the carrier, not as a rejection hours later. Our EDI mapping specification guide shows how to document such rules field by field.

A rejected arrival manifest traced from cutoff to a held box

Most manifest penalties start as an unread rejection, not a missed deadline. The trace below follows one SAM through an Indian gateway, with the figures in the ledger after it priced for illustration beside a comparable US miss on the 24-hour rule.

1. 8 Nov, 22:10 IST: The line's gateway converts a CUSCAR from its Colombo agent into SAM file F_SACHM23_SAM_ICEGATEID_41207_20261108_DEC.json; the agent's free-text value CONSOLIDATED lands in a four-character indicator field.
2. 8 Nov, 22:14: ICEGATE returns an _SFL.json with error code ERR100 and keyword maxLength; the file goes to a shared mailbox that nobody monitors at night.
3. 9 Nov, 06:00: Vessel 118W departs Colombo, its last port of call, with no accepted arrival manifest on file.
4. 9 Nov, 11:30: The day shift finds the failure, corrects the field to the coded value and resubmits; the _ACK.json arrives at 11:52, after departure.
5. 11 Nov onward: The proper officer considers the delay under section 30; container MSKU1234565 waits three extra days at the CFS while the importer's bill of entry is linked to the corrected manifest line.

Indian sea arrival manifests filed as signed SACHM23 JSON on ICEGATE pass a schema check before business validation, and a structural failure file can arrive within 5 minutes; routing every _SFL.json to an on-call queue protects the Customs Act 1962 section 30 deadline, where penalties reach ₹50,000.

Translator rules versus a documentation lead's judgement

A gateway can enforce format, linkage and timing completely; it cannot decide whether a cargo description is truthful or whether a late shipping instruction justifies rolling a box. The split below names the actual tasks, so that nobody expects software to take a decision that customs will hold a person responsible for.

The Indian side of the same work, linking manifest lines to bills of entry and shipping bills inside the ERP, is covered in our guide to ICEGATE bill of entry and shipping bill reconciliation. That guide starts once the manifest is accepted; this one ends there.

Rolling out a multi-country cargo report gateway

Build the gateway in the order customs will test it: schema validation first, acknowledgement handling second, translations third, and only then the go-live cutover per country. The checklist below assumes one internal manifest record feeding CUSCAR, US vessel and truck formats, and ICEGATE SAM.

A gateway built this way lets a carrier add a new customs format without touching how manifests are captured, and makes every rejection visible within minutes. The shipper-to-forwarder message that usually feeds the manifest is explained in our guide to EDIFACT IFTMIN; browse related guides on the logistics and supply chain hub. If you are scoping a manifest or customs integration and want it costed, you can send us your requirements.