Return to Index

EDI Message Management on the CCF

To ensure EDI transactions sent to Customs, and their responses, are processed accurately and meaningfully the CCF will apply common messaging standards for all ICS functions. This section defines the rules and protocols for implementation by both industry and Customs for EDI communications.

NOTE: For use with the Integrated Cargo System an interchange may not exceed 10MB in size.


Message Management Topics

Testing and Development

Interchange Acknowledgement

E-mail Structure

Customs Responses to Inbound Messages

E-mail Address

Responses to Customs for Outbound Messages

Reporting and Recording of Gateway Times

Interchange Sequencing

Format of Times for EDI messaging

Message Sequencing

Document Naming Convention

Negative Values

Rounding Conventions and Negative Values


Batching of Messages



Testing and Development

The ICS will provide a facility for testing and development alongside production. This is to support initial and ongoing development and testing of the ICS.

External users wishing to gain access to test and / or develop should contact the ICS Business Support Unit via email.


E-mail Structure

ICS EDI Interchanges will be carried as attachments to SMTP e-mails in S-MIME format.

  1. E-mails are to be formatted as follows:

    1. One attachment per e-mail.

    2. One Interchange per attachment.

    3. No text to be included in the body of the e-mail . E-mails with text will be rejected without acknowledgement.

    4. The e-mail body and attachment will be encrypted and signed as per Customs PKI requirements.

    5. The subject line in e-mails carrying EDI interchanges to and from Customs will contain plain text data identifying the Interchange. The data will comprise:
      <Interchange Creator ID>_<Interchange Control Reference Number>_<Recipient Site ID>

    6. They will be inserted in the subject line separated with the underscore character with no leading, trailing or included spaces or other symbols. These values are also contained in the Interchange UNB Segment.

      1. NOTE: If plain text responses have been requested spaces will be present in the outbound email subject line.
    7. The file name of the attachment for Inbound e-mails (to Customs) will be:
      <Interchange Creator ID>_<Interchange Control Reference Number>.edi

    8. The file name of the attachment for Outbound e-mails (from Customs) will be:
      <Recipient Site ID>_<Interchange Control Reference Number>.edi

    9. For Inbound e-mails (to Customs) the Recipient Site ID will always be the Customs ID, for Outbound (from Customs) the Interchange Creator ID will always be the Customs ID.

E-mail Address

  1. Interchanges will be transmitted as an SMTP e-mail attachment to an established e-mail address using TCP/IP protocols.This format and address will be common for communicating with the ICS.

  2. Customs addresses will be included in this guide and published on the Customs CMR web site when available.

Reporting and Recording of Gateway Times

  1. Processing times for the CCF and external users should be reported as the date and time for the place of processing.

  2. The CCF will use AEST/AEDST to record dates and times in the UNB segments of Interchanges.

Format of Times for EDI Messaging

The valid reporting range for times is 0000 - 2359. 2400 is NOT a valid time.

Document Naming Convention

The Data item to be reported for document naming is the document name for the message type. Eg, Air Cargo Report document name usage is AIRCR.

Batching of Messages

  1. Each Interchange will contain one or more EDI Messages, formatted according to the UN/EDIFACT Version 3 Syntax rules (ISO 9735).

  2. The number of messages in an Interchange should be limited so that the resulting e-mail attachment is not so large as to become difficult to transport or process. For use with the Integrated Cargo System an interchange may not exceed 10MB in size.

  3. Incoming interchanges should not contain both business messages and control (ICONTROL) messages.

  4. The default size of outbound Interchanges from Customs will be one message.

  5. Clients can specify that their outbound messages are to be batched by Customs on a time and/or message count basis.

    1. Messages can be accumulated for a specified time period or until a specified count is reached, or both, whichever occurs first.

    2. Accumulated Messages will be formed into an Interchange, attached to an e-mail and sent to the client at their nominated e-mail address for responses.

    3. The time setting for accumulating outbound messages will be limited to 10 minutes maximum with a default of zero.

    4. The accumulation count setting will be limited to a maximum of 999 with a default of one.

  6. Response Message batching parameters will be accessible for modification by authorised clients via the Client Register.

  7. Although the message count per Interchange sent by Industry to Customs can be greater than one, as described above, the current advice from Customs is to recommend to clients to use only one. Interchanges containing one message only are processed more efficiently than interchanges containing more than one message.

  8. In addition the message count per Interchange sent by Customs to Industry can also be set to greater than one, as described above, the current Customs advice is to recommend to clients to leave this count at the default value of one. A single message interchange provides the best outcome in terms of overall efficiency of interactions between your system and Customs Cargo systems.

Interchange Acknowledgement

  1. The CCF will respond to all valid Interchanges, containing business transactions, by sending a CONTRL message. The CONTRL message will notify users of gateway receipt and syntactical checking, including limited error reporting.

  2. Interchanges initiating or responding to a business transaction (to and from Customs) must include element 0031 (Acknowledgement Request) in the UNB Interchange header.

Customs Responses to Inbound Messages.


Customs responds to inbound EDI messages with two distinct message types, these are CONTRL messages and Error/Response Messages.

CONTRL messages are generated by the CCF in response to all inbound interchanges. The CONTRL message acknowledges receipt of the interchange and provides information about the acceptance/rejection of the interchange based on its compliance/non-compliance with EDIFACT syntax.
At the CCF CONTRL message level no validation of “business” information is undertaken only compliance with EDIFACT syntax is checked.

After a message has passed through EDIFACT processing (ie EDI validation and the transformation into XML/Business Specific Format (BSF) is completed) CCF undertakes second level validation of the content of the BSF message before passing it through to ICS. BSF represents the format in which information is processed within the ICS.

Second level CCF validation is based on rules provided in the ICS documentation for each release which defines the specific structure and format of each BSF message. The validation encompasses basic syntax checks, including the following:

  1. Mandatory/conditional rules for each element/field
    eg. fields that are defined as mandatory must be present in the message.
  2. Specific type checks for each element/field
    eg. numeric fields are validated to have only numeric values.
  3. Checks on the field lengths supplied in a message, including fixed length and variable length fields
    eg. fields that have fixed lengths defined must not contain values that have varied lengths.
  4. Repeat loops for fields and groups of fields
    Some fields (and groups of fields) can be repeated a defined number of times. CCF checks that repeats are within the defined limits.

If any fields/elements within a message fail a validation check CCF will generate an error response to send back to the client. The response message will be labelled as a genuine response to the inbound message type received (eg CTOREC will be responded to with CTORECR).
Apart from CCF generating its own Document Message Number (prepended with "CCF") a CCF Error/Response message be the same in format and content as the equivalent ICS response message.

If a message has passed CCF primary EDIFACT syntax validation and secondary BSF validation the information is then passed to the ICS where is will undertake ICS “business level” validation.

The ICS may then generate a CUSRES response message containing errors or a business response to the inbound message. Eg. EXD - EXDR

General Response Business Rules.

  1. The CCF will acknowledge received Interchanges with a CONTRL Response message sent to the Interchange Creators sending address.

  2. Duplicate Interchanges will be responded to with a CONTRL response message but not processed.  Duplicate interchanges will be identified by the interchange creator site id and the ICR.

  3. Interchanges using an incorrect format, or lacking a valid digital signature and certificate will be recorded by Customs, but not acknowledged, or processed.

  4. Where Message signatories are not registered on the Customs Client Register a CONTRL error acknowledgement (Code 23) will be sent to the sending address to advise that the signatory is unknown.

  5. The Interchange Control Reference (ICR) from the received UNB will be used to identify the Interchange being acknowledged.

  6. Interchanges may be rejected with a CONTRL error if major structural faults are found.

  7. The CONTRL Response message will contain notification of all Messages in violation of EDIFACT syntax within the Interchange.

  8. All error free messages reported in the CONTRL response have been passed to the ICS for processing.

  9. The CONTRL Response message will use the senders MRN to identify Messages in error within Interchanges.  Messages that are not in error will be passed to the ICS for processing.

  10. Error checking at the CCF is limited to structure and syntax, not data content.  Errors relating to business content will be responded to by the ICS, in a CUSRES message.

  11. Unacknowledged Interchanges should be re-sent to Customs after a defined timeout period.  This action should be repeated a defined maximum number of times.

  12. CONTRL messages received by Customs will not be acknowledged.

Responses to Customs for Outbound Messages

  1. CONTRL messages sent by Customs are not to be acknowledged.

  2. Customs EDI Interchanges responding to a business transaction are to be acknowledged on receipt and safe storage with an ICONTRL Message.

  3. Interchanges not acknowledged with an ICONTROL message will be resent by Customs after a timeout period. This will be repeated a defined number of times. In order to avoid resends and hence to reduce message traffic Customs recommends that an ICONTROL is sent to all Customs messages except the CONTROL message.

  4. Duplicate Interchanges should be responded to with a ICONTRL message but not processed.

  5. The ICONTRL Message will reference the Interchange Owner identity and the Interchange Control Reference from the Interchange UNB received from Customs.

  6. As detailed in Batching Messages it is advised that ICONTROL messages not be sent with other business messages.

Interchange Sequencing

  1. Interchanges are to be numbered sequentially via the Interchange Control Reference (ICR in the UNB at 0020) starting at 1 and incrementing by 1 for each new Interchange.

  2. Interchange Creators are to maintain their own (ICR) sequence, which is to wrap around at 99999999999999 (n14).

  3. Interchanges with an invalidly formatted ICR will not be responded to by Customs.

  4. Customs will maintain a separate sequence for each Interchange Creator.

  5. Customs will process EDI Interchanges in the order they are received by the CCF, on an Interchange Owner (client-by-client) site basis.

    1. The CCF will not wait for a CONTRL acknowledgement to the previous Interchange sent to that client before sending the next Interchange.

    2. Interchanges not acknowledged will be resent when the timeout occurs (see Batching of Messages).

Message Sequencing

  1. Messages within Interchanges are to be numbered sequentially within the Interchange, using the Message Reference Number (MRN in the UNH at 0062). Hence for each Interchange sent the first message will be numbered 1 and incremented by 1 for subsequent Messages contained in the Interchange. The site ID, ICR and the MRN will be needed to identify a particular Message from any one Interchange Creator (client site).

  2. The Messages within Interchanges will be processed by Customs, by message type, in the order they are contained within the Interchange.

  3. Customs responses may not be sent in the order that the originating Message was received. Responses will be sent to the client, as they are made available to the CCF for transmission.


Where the third integer to the right hand side of a decimal indicator is 5 or greater, then the second integer to the left of the decimal point shall be increased by 1 and the third shall be deleted.

5.555 = 5.56
5.668 = 5.67
5.779 = 5.78

Where the third integer to the right hand side of a decimal indicator is 4 or less, then the second integer to the left of the decimal point shall remain unchanged and the third shall be deleted.

5.554 = 5.55
5.663 = 5.66
5.772 = 5.77

Negative Values

Numeric data element values shall be regarded as positive. Although conceptually a deduction is negative, it shall be represented by a positive value and such cases shall be indicated in the data elements directory.

If a value is to be indicated to be negative, it shall in transmission be immediately preceded by a minus sign e.g. -112

The minus sign should not be counted when computing the maximum field length of a data element. However, allowance has to be made for the character in transmission and reception.


  1. Interchanges sent via the Internet may arrive in a different order to when they left the sender (or even go missing). Customs will process in the order of receipt; hence if multiple Interchanges, without intervening CONTRL response messages, are sent some erroneous processing sequences may be attempted. Such errors will receive a CUSRES error response from the ICS application.

  2. Responses to clients sent via the Internet could result in out of sequence replies arriving, particularly Status messages. Client software should be aware of this possibility and process accordingly. For example only record a new Status for an entry if it was sent after (based on time and date) the last Status recorded for the same entry on the client database.

  3. To increase efficiency of transmission and to limit processing overheads at reception, it is recommended that only the significant characters of data elements and component data elements defined as being variable length, should be transmitted. It should be pointed out however, that recipients must have the capability of accepting either suppressed or non-suppressed variable length data, accepting however that processing overheads will be increased if suppression is not used.

  4. Users sending test messages to Customs should be aware that interchanges sent to production with the test indicator set will not be processed by Customs. Interchanges sent to the development/test system without the test indicator set will be processed by Customs, and the resulting Customs response will include a test indicator in the interchange header.


V2.4 15 AUG 2011