Reading an acknowledgement from customs

You filed, and a JSON file came back. This page is about that file: which one you have, what it says, and what to do about each thing it says.

If you are looking up a specific error code, Every ICEGATE error code has all 452 with what to change for each. If your filing has gone quiet and nothing has come back at all, After you file covers that instead.

Which file do I have?

Three different documents come out of a filing, they all arrive as .json, and they look alike at a glance. Telling them apart is the first step, because two of them are answers and one is the thing being answered.

The names are not decoration: ICEGATE parses seven parts out of a filename and refuses anything else before it looks inside the file. The shape is {msgTyp}_{messageID}_{reportingEvent}_{senderID}_{jobNo}_{jobDt}_{kind}.json. Do not rely on the name alone, though — a real filing in our sample set is named …_DEC.json and carries a signature block regardless.

You do not have to work this out by hand. Sign in, go to CSN filing and drop the file on SCMTR JSON upload at the top of the page: it identifies which of the three it is and reads it out.

There are two levels of validation, and only one produces error codes

This catches people out more than anything else on this page.

Structural validation runs first. A file that is malformed against the schema comes back as an _SFL.json carrying JSON-Schema vocabulary and no numbered code at all. If you are hunting a code and there is none, this is why: the file never reached the checks that produce them. The consolation is precision — a structural failure names the exact field by its position in the document, which a business acknowledgement does not.Business validation runs only on a file that passed structurally. That is where every numbered error code comes from, and it arrives in an _ACK.json.

Nothing was ever at stake in a structural failure: no CSN was granted, nothing was recorded against your name. Fix the positions it names and file again.

How do I read an acknowledgement by hand?

It mirrors your filing's own structure and hangs a verdict off each block, so read it block by block rather than top to bottom.

headerField.accpStatus is the overall verdict — Accepted or Rejected.headerField.uniqueId is the transmission id ICEGATE assigned. It identifies the transmission, not the filing.Every block carries its own errorCode array. {"errorCode": "00", "errorMessage": "Successful"} means that block passed. 00 is not an error — it is the positive marker, and on an accepted filing it is nearly all you will see. A file full of 00s with one real code in decRef is telling you exactly where to look.On a refused bill, 00 Successful may mean nothing at all. Customs checks each master bill in two stages. The first is its shape and its reference — codes like 115, 118, 159 and 700. A bill that fails there is never content-checked, and the reply still comes back with 00 Successful stamped on its transhipper, transport document and package blocks, which were not looked at. So read the first real code on a bill, fix that, and expect a fresh set of codes on the next attempt rather than treating the ticks as a clean bill of health. Once a bill passes the first stage, every content error it has is reported together.The version number tells you which side wrote the file. A filing's header carries the message version behind its reporting event — SCE1102 on an import, SCX1102 on an export, SCA1102 on an amendment, and the same pattern on the shipping line filings (SAM1102, SDM1102). Every declaration we have seen follows it, accepted exports included, and the app fills it in for you and keeps it in step with the event. ICES1_5 is customs' own stamp: it is on every acknowledgement and on nothing else. So a file that says ICES1_5 is a reply, not a filing — and if you upload a filing whose version number belongs to a different event (an import file edited into an export, still reading SCE1102), the app points it out in amber.Absent values arrive as the literal string "null", not as JSON null. "csnNmbr": "null" on a rejection means no CSN was granted, which is what you would expect.A code may arrive zero-padded. A real rejection carries "errorCode": "044" for what the MIG's table calls 44, while the success markers in the same file stay "00" — the padding is not applied uniformly, so strip the leading zeros before looking a code up. Both forms mean the same code; the platform reads either.master.decRef.csnNmbr and csnDt carry the CSN and its date on an acceptance. Those two are what every later amendment or deletion references, so they are the ones to keep.Descriptions are not unique — key on the code, never on the text. Six distinct codes read Invalid Destination Port Code.

A worked reading

accpStatus: "Rejected", authPrsn and vesselDtls each carrying 00 Successful, and decRef carrying 700 Error-Refile with csnNmbr: "null". That says: the message was structurally fine, the authorised person and the vessel were accepted, no CSN exists, and the refusal is the one that names no field.

The silence matters as much as the errors

Two things an acknowledgement says besides listing what failed, and both change what to do next.

A block with no code at all was not checked. ICEGATE stops validating at the first record that fails, so on a refusal naming house bill 1 of ten, house bills 2 to 10 carry neither an error nor a 00. That is not nine clean bills — it is nine bills nobody looked at. Correct what failed and the next filing can come back with fresh errors on records that looked fine, which is the checks running for the first time rather than a new mistake. Budget for more than one round.

A block carrying 00 is a positive result you can rely on. On a rejection those marks are the only evidence of what the file got right, and they rule out whole areas. A filer three days into re-filing on the suspicion that their transhipper bond was wrong can read master.mastrCnsgmtDec[0].trnshpr: 00 Successful and stop looking there.

The PCIN in the reply, and when it changes

Each house bill's block in an acceptance ends with hcResponse — cinTyp: "PCIN" and mcinPcin, the Previous Cargo Identification Number customs issued for that house bill. It is what the CFS, the transporter and any later filing that refers to this cargo quote, so it is worth copying out of the acceptance rather than looking for it later. Three things read off real acknowledgements (September 2026):

A fresh acceptance carries one PCIN per house bill; the master's mcResponse is "null" on a forwarder's consolidation.An accepted amendment echoes the CSN number of the filing it changed and returns the PCIN as "null" — the PCIN it already had stands; the amendment does not re-issue it.A fresh re-entry of the same cargo that customs takes is a new CSN and a new PCIN (26PCSE0009053… became 26PCSE0009093… on one bill), so everyone quoting the old one has to be told. See an accepted amendment can empty the record for how that came about.

A reply to a SAM / SDM is a different file

A file named …_SACHM23_…_ACK.json is customs' answer to a SAM / SDM, not to a CSN, and it is read differently: its CINs sit in prevRef rather than mcResponse/hcResponse (on the first real one, an MCIN for each consolidated line), and nearly everything else in it is "null". It carries no CSN number, and that is not a fault. Open it under Shipping line filing — see Customs' reply to a manifest.

An accepted SAM may carry no CIN at all. Customs issues a CIN only for a line that does not quote an earlier declaration. A line that quotes one — previous declaration Y, the forwarder's CSN or MCIN — gets none, so its reference comes back "null" even on an acceptance. A 140-line SAM accepted in September 2026 whose lines all quoted earlier declarations came back with no CIN on any line; nothing was missing.

A manifest acknowledgement is not a copy of the file it answers

It looks like one — the same blocks, the same lines — and that is the trap. On every reply to a SACHM23, accepted or refused, four fields read the same whatever was sent, measured on the replies on record and pinned by the checker:

the header's versionNo reads ICES1_5;decRef.msgTyp reads F, even when the file sent was an amendment;every record's amdType is dropped, even when the file sent carried A, S or D;each line's prevRef reads "null" on a refusal whatever the file quoted, and only an acceptance fills it — with the CIN customs issued.

The SAA that earned an acceptance on record carried SAA1102, A and S; its reply carried ICES1_5, F and nothing. So a refused reply that looks like an amendment filed as a fresh manifest with no amendment type is not evidence that one was — the accepted reply has the identical shape. Never infer what you sent from what came back. Open the file you sent and read its declaration block there; the reply tells you the verdict and the codes, not the message it answered. A first reading of one code-less refusal did infer the send from the echo, and was withdrawn once the accepted specimen was read beside it.

One thing to watch when matching a response to a filing

master.decRef.jobNo is not dependably a job number. In two real acknowledgements for the same job, the accepted one echoed our own job number there and the rejected one put the transmission id in the same field. If you are matching responses to filings by hand, check the filename and headerField.uniqueId too rather than trusting that one field.

What does the verdict actually mean for me?

Accepted. Customs granted a CSN. Keep the number and its date together — an amendment or deletion is defined by referencing both, and the number alone will not match.

Rejected. No CSN was granted, so there is nothing to amend. Correct the declaration and send it again as a fresh filing. It can go under the same control number: a refusal does not use the number up — one filing on record was refused with a 700 and then accepted under its original number the same day — so Refile opens the next attempt under the job's own number. What ICEGATE refuses by email as a duplicate is a number it has already processed for that job date — one that was accepted, or is still waiting for its answer — however much you changed inside the file. If that email ever arrives for a refile, send it again under a fresh number.

Which errors reject the whole filing, and which name one field?

The acknowledgement does not label which kind you have, and the two need opposite responses.

Field-level. One named value is missing, outside its coded list, or the wrong shape. The message tells you the field, the fix is local, and nothing else has to change. Container problems are field-level in this sense too: a bad check digit or an out-of-range size code names one box and leaves the rest alone. Usually a correct-and-resubmit.

Filing-level. The declaration is refused as a whole — not because a value is malformed, but because of what it claims relative to something customs already holds: your filing disagreeing with one that already exists for the same cargo, a prior CSN reference that does not match, a consolidation shape that contradicts the bills present, totals that do not add up across levels, an amendment attempted in a state that forbids it. Worth reading twice before resubmitting, because sending the same claim again with a fresh control number gets the same answer.

A third kind names a record by its number. An amendment finds each record it changes by that record's own number — line, sub-line, a container's sequence, an item's serial — so "Not Exists For Update/Delete" means the number is not there in the filing customs holds now, and "Already Exists For Addition" means a new record took a number already in use. Take the numbers from customs' current version, not an older copy. See An amendment names a record customs does not hold.

A code in no published list is shown with customs' own words for it. Customs sends such codes (700, 705, 748, 749, 753 and more) and words them like the published ones, so when an unknown code says one of the two phrases above, the platform explains it as that and says it read the words to do so. Any other unknown code is shown as it is, with no guess — worth quoting to the ICEGATE helpdesk.

The one that tells you nothing: 700

700 Error-Refile is the refusal filers find hardest to act on, and it appears nowhere in the official 452-code table — looking it up finds nothing, which is why it feels like a dead end. It is the catch-all: no field, no family, no detail beyond the number.

Work it as a checklist. The order is the cheapest check first, not a ranking of causes: nobody outside customs knows what a 700 usually means, and none of the seven on record names a field.

The arithmetic. Packages on each item against its house bill, each house against its master, and the master against the declared equipment and line totals. Then container weights against the declared gross weight.Is it a duplicate transmission? Rarely: ICEGATE answers a re-used number by e-mail ("The Control Number has already been processed"), not with a 700. The number this 700 answered is not used up by it — a refusal frees its number, and every 700 on record (seven) was accepted the same day when sent again, the one whose resend is held under its original number — so the next attempt may go under the same sequenceOrControlNumber. It needs a new one only if an earlier send of the same number was accepted or is still waiting for its answer.The consolidation shape — consolidatedIndctr against the bills actually present, and the consolidator PAN carrying its PAN: prefix.The voyage — the VCN in cnvnceRefNmbr is the number customs issued for that ship's call at that port, not the carrier's own voyage number off the bill of lading — that mix-up is common — or a VCN customs has since replaced because the vessel changed; the filing page says what customs listed for the ship when you filed. A possibility rather than a diagnosis. Every 700 reply read here (seven) marked its vessel and voyage blocks 00 Successful, but one of them also marked 00 on blocks the accepted version of its filing does not contain, so the marks prove little.

Not on the list: the header's indicator. P is production and T test, but customs has accepted filings flagged T — two, each with a CSN issued — so a T is not why a filing was refused.

What ICEGATE itself has said. On 12 September 2026 ICEGATE's engineers told the trade that a 700 on a large file was the system picking the file up and refusing it under database contention at peak time, the same file going through later; ICES Advisory 38/2026 (21 September 2026) says the processing of large manifest files has since been re-engineered, with dedicated background schedulers and new database indexing — an answer about acknowledgement delays that does not mention 700, so that the two describe one path is our reading. So the checklist still stands for a 700 on a small, correct file — the code has other causes — and a 700 that clears on a re-send of an identical file was likely load. Every 700 on record — seven — was accepted the same day when sent again; only one resend is held here, so whether the others went unchanged the record cannot say. Neither account has yet been seen confirmed from customs' side on a filing sent from here.

Filers also name a timeout, an unknown port code, or a wrong PAN, GSTIN or IE code. That comes from filers' experience and is not confirmed; see Why filings get rejected for what is known about each.

Tell yours apart by elimination, not by reading. Upload the declaration alongside the acknowledgement on the SCMTR JSON upload screen and all four are run against your actual file: the first three settled from the file itself, and the voyage from customs' last answer about that ship where one is on record. Each answers pass, fail with the offending value quoted, or an honest "could not be settled" — so what is still open at the end is the short list to work by hand, and a voyage problem shows as the voyage step naming what customs listed at your port instead of your VCN.

Some refusals never become an acknowledgement at all

Not every failure produces a file. Some fail before the message is parsed into a declaration, and ICEGATE reports those by email to your registered address, in prose, with no code to look up. If you are waiting for an acknowledgement that is never coming, check that mailbox.

"Header validation failed … the Control Number has already been processed" — but my file is correct

This is the refusal most likely to arrive on a file that is right in every field. It is not about the declaration at all. ICEGATE is refusing the numbers the file was sent under, not what is inside it, so checking the fields again finds nothing.

What it means: ICEGATE has already processed a file from your sender ID under that job number and job date. Its own FAQ answers it in one line: the job number "has already been used for a filing with the same job date. Please refile using a different job number."

Where the earlier use comes from

An earlier attempt at the same job. The file was corrected and made again, but kept the first version's job number and job date. This is the case on record: job 294 dated 01-09-2026 was made again after a house bill dated 09-09-2026 had been added, and still went out as job 294 of 01-09-2026.Someone else filing under the same sender ID. A colleague, another branch or another software package filing under the same ICEGATE ID keeps its own job numbers, and two of them can land on the same number for the same day.The same file sent twice, for example uploaded again because the first acknowledgement had not arrived yet.

Since 26 September 2026 the platform says this before you sign. Where a file's control number was already used on its job date by a filing it knows of — one sent from here, brought in from the portal or recorded as made elsewhere — Sign & upload shows a note naming that filing and what came of it. It is a note, not a stop: a colleague's filing under another software package is still invisible to it, and if you know the number is free at customs you send as you are.

How to spot it in the file: look for a bill of lading dated after the job date. A job cannot declare a bill that had not been issued yet, so a file like that was made again and kept an older job number and date.

How to rectify it

Pick a job number your sender ID has never used. Check your own register, including filings made from other software.Change it everywhere it appears: the control number in the header, the job number in the job details, and the file name. Set the job date and the header date to today.Only then sign. Editing a signed file breaks the signature, and ICEGATE refuses it with "DSC Failed".Upload it again.

If the earlier filing was accepted (you hold a CSN for it), do not file again at all. Change the accepted filing with an amendment.

What the app checks

Drop the file on SCMTR JSON upload before you send it. You get a notice when either of two things is true:

Amber: a bill of lading is dated after the job date. That is evidence, not proof, because the earlier version may never have been sent.Your organisation already sent or recorded a transmission here under the same sender ID, control number and job date. The notice links to it and says what customs did with it. It is red when customs accepted it or no answer is recorded yet. It is amber when customs refused it (see below for why).

The app cannot see filings made in other software and never recorded here, so no notice does not prove the number is unused. Importing the file as a new draft gives it a new job number and today's date on the way in.

How well is this understood? The meaning is ICEGATE's own FAQ text (September 2025, Q19). The case above was recorded from a real refusal (September 2026, INKAT1). Two things are open:

Which identifier ICEGATE actually compares. The e-mail names the control number, and the FAQ names the job number and job date. Changing all of them, as above, covers both readings.Whether a refused attempt uses up its number. One filing refused with a 700 was sent again the same day under its original number and accepted. So a refusal may not spend the number, and that is why the app shows a refused earlier attempt in amber. A new number costs nothing, so use one anyway.

"There was an error in processing your file… please try after some time"

Worth its own answer, because it is the one email in the table that names nothing wrong with your file — and the instinct it provokes, to go and change something, is the wrong move.

The full wording runs like "There was an error in processing your file with control no. 56314, filing date 20260905, Receiver ID INMAA1, message ID SACHM22. Please try after some time." Read what it does and does not say:

It quotes your control number, filing date, receiver ID and message ID — so the file arrived and was identified. It did not go missing.It gives no error code, no field, no path, unlike a rejection, and no defect, unlike DSC Failed or File is not UTF-8 encoded."Please try after some time" is ICEGATE asking you to send the same thing again later, which is what a system-side or transient failure looks like rather than a bad declaration.

What that means for your filing: nothing was filed. The message never became a declaration, so no acknowledgement is coming and no CSN exists. Do not wait for an ACK on this control number.

How to rectify it

Do not change the cargo data. Nothing in the message points at your content, and editing a filing in response to a transient error is how a good file acquires a real defect.Wait a short while — it asks you to, and the failure is on the side you cannot see.Re-send the same file with a new control number, and a new job number. This is the step that matters. Your control number was received, and this e-mail is not a refusal in an acknowledgement, so whether ICEGATE now counts it as processed is not known — re-sending it risks the documented header failure "The Control Number has already been processed", trading a transient error for a duplicate-transmission one. A new number costs nothing: a control number is a transmission id, not part of the declaration. (A number refused in an acknowledgement, 700 included, is different — that one can go again as it is; see One filing, many transmissions.)If it repeats, stop re-sending and raise it with the ICEGATE Helpdesk, quoting the control number, filing date, receiver ID and message ID from each attempt with its time. Repeated identical failures are no longer transient, and more attempts will not make them so.Watch your deadline while you do this. If the cut-off is near, start the helpdesk ticket in parallel with the retries rather than after them — and see Two companies, one master bill of lading, because the shipping line filing against your master bill closes it to a fresh CSN from you regardless of what ICEGATE's systems are doing.

How well is this understood? The wording is not in ICEGATE's published FAQs, its error-code table, or any document we hold, and it carries no code to look up — it is recorded here from a real refusal (September 2026, INMAA1). The reading above follows from what the message says and from how ICEGATE's other pre-acknowledgement emails behave; treat the "re-file with a new control number" step as the reliable part, since that is documented for the neighbouring cases.

"Your filing was failed due to some error" — an outbound error listing errors in the file

Filers sometimes call this ICEGATE's outbound error. The email gives a tracking id, the sender and receiver ids and your control number, then "Errors in file:" followed by a bracketed list. Each entry is the offending value, a colon, and the rule it broke, for example:

…INFRA VADODAR:Consignee Street Address should be only characters and should not be more than length 70.

How to read it:

Each entry is one value in one field. The same value can appear more than once, because it was filled into more than one field. In the one refusal of this kind on record the address sat on the consignee and the notify party (a notify party "same as consignee"), on two house bills. Each copy has to be fixed."should be only characters and should not be more than length 70" is one message covering two rules. In the refusal on record, the value had nothing in it but letters, digits and spaces, and was 74 characters long. It was the length that failed. Count the characters before you look for anything else.The list does not say which house bill it is on. Search the filing for the quoted value; it may be on more than one.Nothing was filed. No CSN exists and no acknowledgement is coming for that control number.

How to rectify it

Shorten each quoted value to the limit. For an address, the city, state and PIN code have fields of their own, so a city repeated at the end of the street address can usually go.Fix every copy — both parties, and every house bill carrying the same address.Re-file with a new control number. This refusal arrives by e-mail, before any acknowledgement, so whether ICEGATE counts the old number as processed is not known — a new one is the safe choice.

The app now catches this before you file. Text fields whose maximum length ICEGATE's message guide publishes are measured, however the value got there — typed, picked from your address book, or brought in with an uploaded file — and a value that is too long is a red issue in the file inspector and the review step, naming the field, its limit and how many characters to remove. Until September 2026 the limit only stopped you typing past it, so a longer value that arrived any other way was passed as "no issues". Two exceptions, both deliberate: number fields are not measured this way, and two text fields are allowed longer than the guide prints — the HS code, because an accepted filing on record carries ten digits where the guide prints eight, and the destination port, allowed fifteen characters against the guide's ten. A value within our limit on those two is therefore not a promise that ICEGATE will take it.

How well is this understood? Recorded from a real refusal (September 2026, INNSA1). The lengths are the ones ICEGATE's message guide publishes for each field; the email's wording is not in any ICEGATE document we hold.

"Your file … has failed due to UTF-8 encoding validation" — one character that is not plain text

The email names your file and its Unique Id, then asks you to "re-upload the file after correcting the content at line <n> and position <n>". ICEGATE's FAQ calls the same refusal "File is not UTF-8 encoded". ICEGATE turns such a file away before it reads any of the filing, so there is no acknowledgement and no field-by-field list.

What it means: one value holds a character that is not plain text, and the file does not carry it as UTF-8. The email does not say which character, and in the one refusal on record it was never seen, so what follows is our reading rather than an observed cause. The likely sources are values pasted from a PDF, Word or an email — a curly apostrophe or quote (’ “ ”), a long dash (– —), a degree sign (°), an accented letter (É), or an invisible non-breaking space. Software that saves the file in a Windows encoding instead of UTF-8 writes such a character as a byte ICEGATE cannot read, and the whole file fails.

How to read it:

The line is the line of the file, counted from the top, as a text editor counts it. A signed _DECSigned file is the declaration with the signature added after it, so the line is in the declaration, not the signature.The position is most likely a count of bytes from the start of the file, not a column. In the case on record, line 657 sat about 26 KB into the file and the position was 26,624. Go by the line.Nothing was accepted. ICEGATE did log the upload — the email carries a Unique Id — so treat the next send as a new transmission.

How to rectify it

Find the character. Drop the file on SCMTR JSON upload (on the CSN filing page): a file with such a character opens with a notice listing each one by line and column, the field it sits in, and what to type instead. Without the app, open the unsigned _DEC.json in Notepad++, choose Search → Find, tick Regular expression, search for [^\x00-\x7F] and click Find Next: it stops on the character.Retype the value by hand where the file was made, rather than pasting it.Create the file again and sign it again. Never edit the signed file itself — changing a single byte breaks its signature.Re-file with a new control number — the e-mail came before any acknowledgement, so treat the old number as used. If ICEGATE answers "Control Number has already been processed", use a new job number as well.

The app keeps these characters out of a filing you make here. Typing or pasting into any text field converts them as you go — ’ to ', – to -, a non-breaking space to an ordinary space, É to E — and drops anything with no plain equivalent. A value that arrives any other way (an imported file, a pre-fill, the address book) is checked instead: a character that could not be read is a red issue, because the file it came from was not UTF-8; any other character outside plain text is an amber one. Customs has accepted a correctly saved non-breaking space (seven filings, in a consignor's country name), and no other such character appears on a filing on record — but none has been seen refused either. What ICEGATE refuses is the file's encoding, not the character.

How well is this understood? Recorded from a real refusal (September 2026, Chennai), for a file made in other software; the character itself was not seen. ICEGATE's FAQ (September 2025, question 22) says the file must be UTF-8 and that the email names the line and position. That every filing on record is plain text is measured across all of them, and so is the one exception: a correctly encoded non-breaking space on seven accepted filings. That the position counts bytes is inferred from the one case.

What the platform does with one for you

Drop an acknowledgement on CSNs → SCMTR JSON upload and it will — for one of your own filings, recording the outcome against it as well:

say which of the three files it is, and read the verdict into plain words;take every error in turn — what the code means in the official wording, where in the filing it sits, whether it refuses the whole filing or names one value, and numbered steps for that specific code;run the 700 checklist against your declaration if you upload that too, and mark each error onto the block it belongs to with the offending value shown;tell you which of your filings it answers, if it answers one, and offer to record the outcome against it so the filing's own page carries the result and the file behind it.

Recording an outcome is the only thing on that screen that saves anything, and it asks first. An outcome recorded from a file you uploaded is marked as such, so it is never mistaken later for one ICEGATE handed us directly.

If you already know which filing it is for — you are looking at it — skip the hunt: drop the file onto the filing itself, from ⋯ → Upload ACK on its row or the Status card on its page; or drop it on SCMTR JSON upload at the top of the CSN filing page and let the file name the filing. Either way the status and details are set from the file and every error is explained against the payload that was sent. Dropped on a filing, a file for a different job is refused before anything is written — judged on what the file carries, not its name, whose date is the day ICEGATE replied and can sit a day after the filing's. Dropped on the CSN filing page, a file that answers none of your filings is not refused: it opens in the checker, explained, with nothing recorded. After you file walks through it.

And when you pair an acknowledgement with its CSN on SCMTR JSON upload, the screen tells you which file to look for — the CSN's full six-part name, read off the acknowledgement's own name where ICEGATE kept it, and recovered part by part from the body where the file was renamed — and refuses a CSN that is not the one the acknowledgement answers, rather than anchoring errors onto the wrong document.

It reads the two things that are not errors, too. Under the problems it lists the blocks customs marked good — so a rejection tells you what is already right as well as what is not — and the records customs never reached, named with their bill numbers, so nine unstamped house bills are not mistaken for nine clean ones.

And it can explain a combination refusal. 115 and 118 name four fields at once and none of them usefully. The platform works them back through the MIG's own table of accepted combinations: with the CSN to hand it quotes your four values, says which cannot stand, and names what the table allows instead. See Cargo type, movement and the combination customs checks.

Related

Every ICEGATE error code — all 452, by family and by numberWhy filings get rejected — the causes, by error code, and what to changeCargo type, movement and the combination customs checks — the table behind 115, 118 and 126One consignment, several transmissions — which of two acknowledgements answers the CSN in front of you, and why the date in the name is the day ICEGATE repliedAfter you file — waiting, tracking, and recording an outcome by handAmendments and deletions — what to do once a filing is accepted