ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
ACE (AE/AX)
(A) EDI Messaging Standard
(A1) What Electronic Data
Interchange (EDI) messaging
standard is used:
Conventional, CBP Automated Broker Interface (ABI)
proprietary 80-character ‘image’.
----- No Change -----
Multiple Entry Summary ‘transactions’ are allowed in a
single B-, Y-Record envelope.
----- No Change -----
Multiple Entry Summary B-, Y-Record envelopes (blocks)
are allowed in a single A-, Z-Record envelope.
Multiple A-, Z-Record envelopes (batches) are allowed in a
single transmission. There is no guarantee that multiple
A-, Z-Record envelopes transmitted to ACS in a single data
burst shall be processed and responded to in the received
order.
An output A-, Z-Record envelope (batch) ONLY is
generated and returned. Enclosed input B-, Y-Record
envelope (blocks) (or any transaction data enclosed) are
not evaluated. The output batch does NOT enclose any
blocks.
An output B-, Y-Record envelope (block) is generated and
returned (enclosed in an output A-, Z-Record envelope
(batch)). Enclosed input transactions in that block are not
evaluated. However, the validity of one input block has no
bearing on the acceptance of any other input block.
----- No Change -----
(B) Batching and Blocking
Entry Summary Transactions
(B1) How Entry Summary input
transactions are allowed to be
‘blocked’:
(B2) How Entry Summary input
‘blocks’ are allowed to be ‘batched’:
(B3) How multiple input ‘batches’ are
allowed to be transmitted:
(B4) How ‘batch’ syntax violations
and authentication failures are
returned in the output.
(B5) How ‘block’ syntax violations
and authentication failures are
returned in the output.
----- No Change -----
(Note: ACE transaction batches may be commingled with
existing ACS transaction batches.)
----- No Change -----
An output B-, Y-Record envelope (block) is generated
and returned (enclosed in an output A-, Z-Record
envelope (batch)). Enclosed input transactions are not
evaluated.
All syntax (batch, block, and transaction level) violations
and all authentication failures result in a batch level
rejection. Transaction level business data evaluation
does not take place.
(C) Entry Summary Transaction
Application ID
(C1) What ‘application ID’ is used
(input):
(C2) What ‘application ID’ is used
(output):
2/8/2016
EI
Response B-Record Application Identifier Code: ER
Input B-Record Application Identifier Code:
ACE ABI CATAIR
AE
Response B-Record Application Identifier Code: AX
Input B-Record Application Identifier Code:
Page 1 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(D) Trade Documentation
ACS CATAIR:
 ‘Application Control’ chapter
 ‘Entry Summary’ chapter
 ‘Other Government Agencies’ chapter
ACE (AE/AX)
ACE CATAIR:
 ‘ABI Batch & Block Control’ chapter
 ‘Entry Summary Create / Update’ chapter
ACS CATAIR:
 ‘Other Government Agencies’ chapter
(D1) What CATAIR document
contains the ABI batch and block
record descriptions:
(D2) What CATAIR document
contains the ABI Entry Summary
record descriptions:
Existing ACS CATAIR ‘Application Control’ chapter.
Existing ACS CATAIR – ‘Entry Summary’ chapter.


(D3) How the filing rules are
described in the Entry Summary
CATAIR:
Also includes a section on ‘Statement Delete
Transaction’ (HP) and ‘Electronic Reject / Request’
(US).
OGA data (FDA, DOT/NHTSA, & FCC data) described
in the ACS CATAIR ‘Other Government Agencies’
chapter.
In the ACS Entry Summary CATAIR chapter, generally in
the record description tables and the ‘notes’ that follow
each.
Transitional documents:
 ACS EI to ACE AE Record Layout Cross Reference
 ACS to ACE Entry Summary Condition Cross
Reference
 EDI ES Filing & Response Scenarios – TRADE
 AE Entry Summary Examples
ACE CATAIR ‘ABI Batch & Block Control’ chapter.
ACE CATAIR ‘Entry Summary Create / Update’
chapter; completely supersedes existing document (for
an ACE filed Entry Summary).





(D4) How changes to the filing rules
are communicated:
2/8/2016
Additional and changed information regarding an Entry
Summary submission/EDI filing is communicated via the
Cargo Systems Messaging Service (CSMS).
ACE ABI CATAIR
Describes the Entry Summary transaction (AE/AX)
ONLY.
Includes the FCC data records.
FDA & DOT/NHTSA data described in the in the ACS
CATAIR ‘Other Government Agencies’ chapter.
Limited information is provided in the record
description tables and the ‘notes’ that follow. In the
AE CATAIR chapter, this information is meant to
provide generic, basic filing information (i.e., that used
in EVERY filing scenario).
A separate Entry Summary Filing Usage Note section
categorizes and describes many of the Entry
Summary ‘filing’ requirements. This section, however,
is not meant to be all inclusive and may not cover all
‘business rules’. Sections will be expanded and others
included as needed.
----- No Change -----
Page 2 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(D5) How repeating groups of
records are described in the Entry
Summary CATAIR chapter:
Limited information provided. The actual limit of some
repeating groupings is not entirely clear.
ACE (AE/AX)


(D6) How related Entry Summary
data elements are ‘grouped’ in the
input records:
Numerous record/data element modifications made
between 1984 and 2008. In some cases data elements
were added to existing records simply because filler was
available – resulting in some illogical configurations.




(D7) How ‘data class’ (e.g.,
alphanumeric) is specified for an
individual data element:
2/8/2016
Some ambiguous and inconsistent data class usage.
ACE ABI CATAIR
A ‘structure map’ illustrates how the automated
interface expects repeating groups to be configured
(both input and response).
A loop repeat limit is specified for each grouping (both
a transitional ACS limit and the future ACE limit).
Entry Summary data elements reorganized into more
logical groupings.
Unused and retired records and data elements
eliminated.
Some related business data elements regrouped for
conditional inclusion (e.g., Bonds, ADD/CVD).
Multiple tariffs regrouped into single repeating record.
‘ACS EI to ACE AE Record Layout Cross Reference’
provides a complete cross reference of all EI and AE data
elements.
 A record layout ‘key’ is provided that unambiguously
defines the data classes.
 The data class specified for a data element (or in
some cases more than one data class) is meant to
cover all reporting scenarios.
Page 3 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(D8) How mandatory & conditional
Entry Summary data reporting is
specified:
Information is provided throughout the chapter. In cases,
however, it is ambiguous and inconsistent.
ACE (AE/AX)
Mandatory and conditional Entry Summary data reporting
instructions are noted throughout the document:


(D9) How the output response
records are described:
Three explicit types of ER output response records are
described:




EXX – Describes a single Entry Summary ‘error’
condition (where ‘XX’ is the input record ID in ‘error’).
E0 – Describes the CBP disposition (e.g., rejected or
accepted) for the Entry Summary portion of the filing.
EC – Describes a single ‘error’ condition and CBP’s
disposition of a request to ‘certify’ for cargo release.
(Note: In EI, the input record that caused, or contributed, to
the ‘error’ condition, is returned in the output response as
well as an aid to identify where the ‘problem’ has occurred
[i.e., a ‘signpost’].)
2/8/2016
In the input record ‘structure map’.
In the designation column in each record description
table.
 In the Entry Summary Filing Usage Note section of
the chapter.
Two types of AX output response records are described:
ACE ABI CATAIR

E0 – Unconditionally retuned to identify the Entry
Summary transaction; others conditionally returned to
identify the repeating group of the input where a
condition (e.g., fatal, warning) arose (i.e., a
‘signpost’).
E1 – Describes a single, discreet condition regarding
an input validation or the final disposition of the
requested action for the transaction.
(Note: The result of a request to ‘certify for cargo release’
shall no longer be returned in an Entry Summary
response.)
Page 4 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(D10) How ‘fatal’ and ‘warning
conditions are identified and how
problems filings are resolved:



The Narrative Text of the E0-Record provides
information regarding the condition (identified by the
E0-Record Error Message Identifier).
A specific ‘error’ code (and accompanying text) may be
used for more than one reason/condition.
A comprehensive directory of Entry Summary EI filing
conditions does not exist.
ACE (AE/AX)



With the exception of certain Census Warning codes,
the existing EI codes will not be used; AE will
generate completely different codes.
The generated text for a condition is more specific.
The text will cite the reason; not the conclusion.
A condition code directory/problem resolution guide is
in the planning stages.
‘ACS to ACE Entry Summary Condition Cross
Reference’ provides a complete cross reference of all EI
and AE generated conditions.
(E) Entry Summary Transaction
Syntax Evaluation
(E1) SYNTAX: At what level Entry
Summary transaction ‘syntax’ is
evaluated:
For the most part, record order and other syntax is
evaluated at the transaction level (i.e., Entry Summary
Header – 10-Record through 90-Record). However, the
definition of syntax is somewhat unclear; application of
syntax rules are inconsistent:
Syntax evaluation, for ALL records included in an Entry
Summary batch, is at the batch level (i.e., A- thru ZRecord):



(E2) SYNTAX: How a missing Entry
Summary Header (10-Record) is
tolerated:
(E3) SYNTAX: How an unknown
record ID is tolerated:
A missing 10-Record (following the B-Record or a 90Record) results in that single transaction being rejected.
(E4) SYNTAX: How an illogically
sequenced record is tolerated:
A known record found out of sequence results in a single
transaction being rejected.
(E5) SYNTAX: How an excessive
record in a grouping is tolerated:
An ‘overflow’ of a grouping (i.e., a ‘loop limit’ exceeded)
results in a single transaction being rejected.
2/8/2016
An unknown record (i.e., an unrecognized control identifier)
is ignored.
ACE ABI CATAIR
A syntax failure encountered in ANY input record in
the batch will result in the ENTIRE batch being
rejected.
Syntax is evaluated FIRST; business data evaluation
shall not take place if syntax failure is encountered.
The FIRST syntax violation causes all validation for
that batch to immediately cease.
(Note: Syntax does not include numeric and valid date
checks – in AE, these shall be considered as a business
tier validation.)
A missing 10-Record (following the B-Record or a 90Record) is a syntax failure and results in the entire batch
being rejected.
An unknown record (i.e., an unrecognized control
identifier) is a syntax failure and results in the entire
batch being rejected.
A known record found out of sequence (i.e., does not
conform to the input ‘structure’ map) is a syntax failure
and results in the entire batch being rejected.
An ‘overflow’ of a grouping (i.e., a ‘loop limit’ exceeded) is
a syntax failure and results in the entire batch being
rejected.
Page 5 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(E6) SYNTAX: How a record that
contains no data is tolerated:
While there are exceptions, a ‘blank data’ record (i.e., a
recognized control identifier followed by blanks)
conditionally results in a fatal rejection (based on a
‘missing data’ business rule).
ACE (AE/AX)
With one exception:

A ‘blank data’ record (i.e., a recognized control
identifier followed by blanks) is a syntax failure and
results in the entire batch being rejected.
For ACS compatibility reasons, an EXCEPTION to the
rule:

(E7) SYNTAX: How a record that
contains a ‘non-contiguous’ (side-byside) item is tolerated:
In a repeating group within a single 80-character record,
handling of repeating data elements not found to be left
justified is handled in an inconsistent manner.
(E8) SYNTAX: How data found in a
Data Element defined as ‘Filler’ is
tolerated:
Data found in ‘Filler’ is ignored.
(E9) How a missing record (other
than the Entry Summary Header 10-Record) is tolerated:
Handled in an inconsistent manner. Some missing records
are considered as a syntax violation resulting in a fatal
rejection.
(E10) How non-numeric data in a
numeric data element is tolerated:
Non-numeric data found in a numeric data element results
in a fatal rejection.
(E11) How an unknown date found in
a date data elements is tolerated:
An unrecognizable data string found in a date data element
results in a fatal rejection.
2/8/2016
ACE ABI CATAIR
FD03-Record.
(Note: This syntax failure is slated to be removed.)
In a repeating group within a single 80-character record,
repeating data elements not found to be left justified is a
syntax failure and results in the entire batch being
rejected. (Example: Release Detail – 32-Record.)
Data found in ‘Filler’ is a syntax failure and results in the
entire batch being rejected.
(Note: This applies to an AE filing only.)
In AE, a missing record (or a missing group) (other than a
case in which the record position does not conform to the
input ‘structure map’) is NOT a syntax failure. The AE
business data validations will ensure that all required data
elements are present. A missing data ‘condition’ (fatal)
may be co-mingled with other fatal and/or warning
conditions.
In AE, non-numeric data found in a numeric data element
is NOT a syntax failure. A non-numeric data ‘condition’
(fatal), however, will be raised and may be co-mingled
with other fatal and/or warning conditions.
In AE, an unrecognizable data string found in a date data
element is NOT a syntax failure. An unknown date
‘condition’ (fatal), however, will be raised, and may be comingled with other fatal and/or warning conditions.
Page 6 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
ACE (AE/AX)
(F) Other Entry Summary Data
Normalization
(F1) How numeric (count and
amount) data elements are reported:
(F2) How one-character ‘indicators’
are reported:
Various data class variations recognized; depends on the
data element:
Data class across all count and amount data elements
consistent. Two data classes allowed:





All numeric (e.g., ‘0000001234’)
Leading space numeric (e.g., ‘
All blank implies zero.
1234’).
For various one-character ‘indicators’ (i.e., a data element
that has only two choices), a variety of values supported
(depends on the data element):




‘Y’ & Blank.
‘1’ & ‘0’.
‘Y’ & ‘N’.
In addition, some indicators are an abbreviation for a
business term (e.g., ‘E’ = an EIP Entry Summary, etc.).
All numeric (e.g., ‘0000001234’)
Leading space numeric (e.g., ‘
1234’). (Note:
Leading space number is being allowed because
some existing trade participants submit EI data in this
manner. A count or amount data element is not
required to have leading spaces; if submitted
however, leading spaces will be tolerated).
(Note: All blanks no longer allowed.)
The values accepted for a one-character ‘indicator’ (i.e., a
data element that has only two choices), shall be limited
and consistent:

‘Y’ (Yes) & Blank (No).
(G) Entry Summary ‘Actions’
(G1) What Entry Summary ‘actions’
are supported:
Four actions recognized:




Three actions recognized (10-Record Summary Filing
Action Request Code):
A (Add).
R (Replace).
C (Change).
D (Delete).



(Note: Add, Change, and Replace can be used
interchangeably to establish a new and correct/amend an
existing Entry Summary.)
2/8/2016
ACE ABI CATAIR
A (Add).
R (Replace).
D (Delete).
The C (Change) action has been eliminated. (Note: Add
and Replace can be used interchangeably to establish a
new and correct/amend an existing Entry Summary.)
Page 7 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(G2) How the Add action differs from
the Replace action:
Use the A (Add) action to:


ACE (AE/AX)
----- No Change -----
Establish an initial Entry Summary.
To correct an existing Entry Summary when the initial
filing of the Entry Summary included a Broker
Reference Number (10-Record). The Broker
Reference Number specified in the transaction MUST
match exactly that reported in the initial filing.
Use the R (Replace) action to:


(G3) What Entry Summary records
and data elements are allowed in a
Delete transaction:


Establish an initial Entry Summary.
To correct an existing Entry Summary without
checking that the initial Broker Reference Number, if
any, matches the replacement Broker Reference
Number, if any.
Inclusion of other records will result in a fatal rejection.
The Entry Summary, however, is still deleted if found
(and is in a state that allows its deletion).
Data elements in the 10-Record that are not germane
to the Delete action are allowed (e.g., Bond Type); no
validation occurs, however.


Only the 10-Record is allowed; inclusion of other
records will result in a fatal rejection.
Entry Filer Code, Entry Number, District/Port of Entry,
and Entry Type Code are required. Broker Reference
Number is allowed (but is not required to match what
is on file). All other data elements in the 10-Record are
NOT allowed.
(H) Response to an Entry
Summary Transaction
(H1) How an accepted Entry
Summary response can be
suppressed:
As an option, the Filer can specify that ONLY ‘rejected’
transaction responses are returned in the response block;
successful transaction responses are suppressed.
(H2) How multiple Entry Summary
response transactions are ordered in
the output:
The order of the output response Entry Summary
transactions (within a single response block) shall be the
same as the input transaction.
2/8/2016
ACE ABI CATAIR
The suppression feature is no longer supported.
A response to each and every input Entry Summary
transaction shall be unconditionally returned in the
response block.
----- No Change -----
Page 8 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(H3) How the Entry Summary is
identified in the response transaction:
A single, consistent method shall be used:
EITHER:
ALWAYS, both:


When a fatal or warning condition is found, the input
10-Record is returned (unchanged). The 10-Record
contains Entry Filer Code/Entry Number.
OR

(H4) How the ‘problem’ input (record
or data element) is identified in the
Entry Summary response when a
condition has arisen:
ACE (AE/AX)
Two methods are used:
When the Entry Summary action has been
unconditionally accepted, an E0-Record is returned
(data elements Entry Filer Code and Entry Number are
populated).
A somewhat inconsistent method is employed:


The input 80-character record (or records) that caused
or contributed to the condition are returned,
unchanged, in the output response. These records act
as a ‘sign post’ (i.e., helps the trade participant and
Client Rep to identify where the problem was found).
As many input records are returned as needed to
identify the hierarchy of groupings.
An EXX-Record follows (where ‘XX’ is the input record
ID in ‘error’). At times, however, the ‘EXX’ points to a
missing record’s identifier (which can lead to
confusion).
An Entry Summary Condition Reference (E0-Record)
where Reference Data Type Code = ‘SUMMRY’ shall
be returned (as the first record for the transaction).
The Entry Filer Code, Entry Number, and Broker
Reference Number from the input 10-Record are
included.
 Each Entry Summary Condition/Disposition
Response (E1-Record) that denotes the disposition
shall be returned (as the last record for the
transaction). The Entry Filer Code, Entry Number,
and Broker Reference Number from the input 10Record are included.
A consistent method shall be employed.





One or more E0-Records (Entry Summary Condition
Reference) shall be returned that identify the
grouping where a condition (e.g., fatal, warning)
arose. This record acts as a ‘sign post’ (i.e., helps the
trade participant and Client Rep to identify where the
problem was found). As many E0-Records are
returned as needed to identify the hierarchy of
groupings.
The individual record is NOT identified.
The Reference Data Type Code data element
identifies the grouping.
The Occurrence Position data element identifies the
relative position of the item in the group. (E.g.,
‘LINITM 000007’ would point to the 7th input Entry
Summary Line Item Grouping.)
Variable fields on the E0-Record contain other
pertinent data found in the input. (E.g. the ‘TARIFF’
E0-Record would return the input 50-Record HTS
Number data element.)
(Note: A copy of the submitted input record shall no
longer be returned).
2/8/2016
ACE ABI CATAIR
Page 9 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(H5) How a fatal, warning, or
informational condition is identified in
the response:
The Error Message Identifier data element of the EXXRecord is returned with a code that corresponds to the
Narrative Message data element.
ACE (AE/AX)
An E1-Record (Entry Summary Condition/Disposition
Response) shall be generated and returned for each
condition encountered following the E0-Record(s) that
identifies the grouping(s). The Condition Code data
element shall be populated with a code that corresponds
to the Narrative Text data element.

(H6) How the severity of a condition
is identified in the response:
A condition’s severity is implicit:
‘ACS to ACE Entry Summary Condition Cross
Reference’ provides a complete cross reference of all
EI and AE generated conditions.
 With the exception of certain Census Warning codes,
the existing EI codes will not be used; AE will
generate completely different codes.
A condition’s severity is explicit:




(H7) How a rejected transaction is
identified in the response:
2/8/2016
The individual severity of a condition not conveyed in
the output response.
In some case the Narrative Message Text of the EXXRecord includes the word ‘WARNING’.
The overall severity of the transaction only reflected in
the final ‘disposition’ EXX-Record (i.e., ‘TRANSACTION
DATA REJECTED’) or E0-Record (e.g., ‘ENT ACCPTD
W/WARNING;NO DOC REQRD’.
In ACS, BOTH fatal and warning ‘errors’ may be comingled in the transaction’s output response.
The Error Message Identifier data element of the
‘disposition’ EXX-Record contains code ‘524’; the Narrative
Message data element contains ‘TRANSACTION DATA
REJECTED’.
ACE ABI CATAIR
The Severity Code of each E1-Record shall indicate
the severity of the individual condition (F = Fatal; W =
Census Warning; I = Information Only)
In ACE, fatal, warning, and informational conditions may
be co-mingled in the transaction’s output response.
An Entry Summary Condition/Disposition Response (E1Record) that denotes the rejected disposition shall always
be returned (as the last record for the transaction). The
Disposition Type Code data element shall contain ‘R’; the
Condition Code data element shall contain ‘998’; the
Narrative Text data element shall contain ‘TRANSACTION
DATA REJECTED’.
Page 10 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(H8) How an accepted transaction is
identified in the response:
The Error Message Identifier data element of the
‘disposition’ E0-Record contains a code that corresponds
to the Narrative Message data element.
When the Entry Summary transaction is accepted in an
Add or Replace scenario, a response is returned that
reflects BOTH the CBP action and the state of the
‘documentation’:







‘PAPERLESS - FILER RETAIN RECORDS’.
‘ENTRY REPLACED - DOCUMENTS REQD’.
‘ENTRY ACCEPTED, PAPER NOW REQD’.
‘ENTRY ACCEPTED WITHOUT ERRORS’.
‘ENTRY ACCEPTED WITH WARNINGS’.
‘ENT ACCPTD W/WARNINGS; PAPER REQD’.
‘ENT ACCPTD W/WARNING;NO DOC REQRD’.
When the Entry Summary transaction is accepted in a
Delete scenario, a single response is returned:

‘ENTRY HAS BEEN DELETED AS REQUESTED’.
ACE (AE/AX)
An Entry Summary Condition/Disposition Response (E1Record) that denotes the acceptance disposition shall
always be returned (as the last record for the
transaction). The Disposition Type Code data element
shall contain ‘A’. An acceptance response shall reflect
ONLY the CBP action. The Condition Code and
Narrative Text data elements are as follows:



Code ‘995’; Text ‘SUMMARY HAS BEEN ADDED’.
Code ‘996’; Text ‘SUMMARY HAS BEEN REPLACED’.
Code ‘997’; Text ‘SUMMARY HAS BEEN DELETED’.
In the case of an Add or Replace, the code/text returned
will reflect ACE’s file maintenance action and may not
correspond to what the Filer specified in the 10-Record
Summary Filing Action Request Code. For both an Add
or Replace action, the Severity Code shall reflect the
most severe of the entire transaction.
A ‘documents required’ or ‘paperless’ type of response
shall no longer be returned. An Entry Summary Status
Notification (transaction identifier: UC) will be sent to the
Filer, when needed.
(I) Entry Type / ACS-to-ACE
Crossover
(I1) What Entry Types are allowed.
2/8/2016
All conventional Entry Types (including 01, 03, and 11) are
allowed in the EI transaction with the exception of Deferred
Duty (08), Reconciliation (09), and Drawback (4x). These
Entry Types may be submitted to ACS using an ABI
transaction specifically designed for the Entry Summary’s
unique requirements.
ACE ABI CATAIR
Entry Types 01, 03, and 11 allowed only.
If other known conventional EI supported Entry Type
encountered, fatal condition B19 – ‘ENTRY TYPE CODE
NOT YET SUPPORTED IN ACE’ will be raised.
Page 11 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(I2) What Entry Summary can be
conditionally replaced (corrected) or
deleted.
ACE (AE/AX)
An ACE initiated Entry Summary will be received from ACE
for collection, liquidation, and other actions not yet
supported in ACE.
An ACE initiated Entry Summary will be sent to ACS for
collection, liquidation, and other actions not yet supported
in ACE.
Conditionally, an Entry Summary initially submitted in ACE
via AE cannot be corrected using EI. (Note: Only an ES
initially submitted in ACE that has been deactivated in ACE
and then added in ACS via the EI can be corrected or
deleted via the EI.)
An Entry Summary initially submitted in ACS via EI cannot
be corrected or deleted using AE.
When the Entry Summary is found to be an ACS Entry
Summary, fatal condition B27 – ‘ACTION NOT ALLOWED
- NON-ACE SUMMARY’ will be raised.
When the Entry Summary is found to be an active ACE
Entry Summary, fatal condition AN1 – ‘ACE: ENTRY REC.
BELONGS TO ACE’ will be raised.
(J) Entry Summary Program
Support
(J1) What ‘remote’ filing is allowed.
Remote Location Filing (RLF) is conditionally allowed:
----- No Change -----


(J2) What invoice related submission
is allowed:
Filer must be a Broker that has a national ‘filing’ permit.
Requires coordination with the Client Rep to ‘set up’ an
RLF profile.
 B-Record Remote Filed Indicator must be ‘1’.
 B-Record Remote Preparer D/P, Filer must be present.
 An RLF filing requires that the submission is also an
Electronic Invoice Program (EIP) filling as well.
Electronic Invoice Program (EIP) is conditionally allowed:
Electronic Invoice Program (EIP) is conditionally allowed:







2/8/2016
The 10-Record Electronic Invoice Indicator must be
marked ‘E’.
Filer must be authorized to participate in the Automated
Invoice Interface (AII) program.
The Entry Summary must have a continuous bond.
The Entry Summary must initially be a statement entry.
The 30-Record Summary Certification Code data
element must be marked ‘1’ (i.e., “paperless”).
The submission must include a 42-Record that cites the
commercial invoice and invoice line number(s) on each
and every Entry Summary line item.
ACE ABI CATAIR




The 10-Record Electronic Invoice Indicator must be
marked ‘Y’.
Filer must be authorized to participate in the
Automated Invoice Interface (AII) program.
The Entry Summary must have a continuous bond.
The Entry Summary must initially be a statement entry.
The submission must include a 42-Record that cites
the commercial invoice and invoice line number(s) on
each and every Entry Summary line item.
(Note: The submission no longer needs to be marked as
‘paperless’.)
Page 12 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(J3) What ‘paperless’ designation
and ‘electronic signature’ is allowed:
When set to a ‘1’, the 30-Record Summary Certification
Code data element is an indication of the Filer’s willingness
to accept a paperless designation for the Entry Summary.
(J4) What payment intent methods
are allowed:
Three methods are supported in ANY filing:



(J5) How Cargo Release Certification
is supported and how cargo release
related conditions are returned:


(J6) How a ‘consolidating’ Entry
Summary submission is supported:
2/8/2016

Single Payment.
Daily Statement.
Monthly Periodic Statement.
The 30-Record Release Certification Code data
element marked with ‘1’ is an indication that the Filer
is requesting the accepted Entry Summary be used for
cargo ‘release’ purposes.
In the ER response transaction, following the E0Record (when the Entry Summary has been accepted)
one or more EC-Records are returned that describe
any fatal or warning conditions found, or the
acceptance, of the ‘cargo certification’ process.
The 30-Record Consolidated / Informal Indicator data
element marked with ‘C’ is an indication the Entry
Summary is ‘consolidating’ the ‘releases’ cited in the
32-Record(s).
ACE ABI CATAIR
ACE (AE/AX)

An indication that the Entry Summary is ‘paperless’
has been eliminated.
 In its place is an ‘Electronic Signature’ (10-Record
Electronic Signature data element = ‘X’). This
signature is required on ALL Entry Summary ‘add’ and
‘replace’ submissions.
Two methods are supported in the INITIAL filing:


Daily Statement.
Periodic Monthly Statement.
(Note: ONLY if Filer has removed the Entry Summary
from the statement using the ACS HP transaction will the
Single Payment method be allowed. The Entry Summary
MUST initially be a statement entry).
 The 10-Record Cargo Release Certification Request
Indicator data element marked with ‘Y’ is an indication
that the Filer is requesting the accepted Entry
Summary be used for cargo ‘release’ purposes.
 If the Entry Summary transaction is accepted, ACE will
forward the cargo release information to ACS for the
‘cargo certification’ process.
 The AX response output transaction will NOT contain
any information regarding the success or failure of the
‘cargo certification’ process.
 A subsequent response will be generated and
returned to the Filer from ACS (i.e., an HD response
output transaction).
 The 10-Record Consolidated Summary Indicator data
element marked with ‘Y’ is an indication the Entry
Summary is ‘consolidating’ the ‘releases’ cited in the
32-Record(s).
Page 13 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(J7) When FCC form data is
allowed/required:
(J8) When FDA form data is
allowed/required:

FCC form 740 information is required to be submitted
at the tariff level when the HTS is marked as ‘FCC-740
required’ (i.e., ‘must’).
 Either the FCC form 740 information must be submitted
or disclaimed at the tariff level when the HTS is marked
as ‘FCC-740 may be required’ (i.e., ‘may’).
 For any tariff, the FCC form information will be
accepted (i.e., a ‘voluntary’ submission for a tariff
marked neither ‘must’ nor ‘may’).
Full Entry Summary support of FDA form data submission:


When FDA form 701 / BTA information (or disclaimer)
is submitted and accepted at the tariff level it is
conveyed to the cargo system (in a non-Line Release
scenario). The information is sent to FDA and is used
to determine the release of the cargo.
When the cargo has already been released via a Line
Release mechanism (e.g., FAST), the FDA form 701
information is required (or may be disclaimed) based
on the HTS requirement. The information is sent to
FDA.
ACE (AE/AX)
----- No Change -----
Limited Entry Summary support of FDA form data
submission:


An FDA form 701 / BTA (or disclaimer) submission at
the tariff level will ONLY be accepted when Cargo
Release Certification has been requested. ACE will
forward the FDA information to ACS for the ‘cargo
certification’ process (including the validation of the
data).
The Entry Summary shall fatally reject when the
cargo has been released via a Line Release
mechanism and any tariff requires or may require
FDA data. This type of Entry Summary must be
submitted in ACS (using the EI transaction).
(Note: An Entry Summary that correlates to a Line
Release that does NOT have any FDA concerns may be
submitted into ACE using the AE transaction.)
2/8/2016
ACE ABI CATAIR
Page 14 of 15
ACS EI-to-ACE AE Feature Comparison
ACS (EI/ER)
(J9) When DOT/NHTSA form data is
allowed/required:
Limited Entry Summary support of DOT/NHTSA form data
submission:



When DOT/NHTSA form HS-7 information (or
disclaimer) is submitted and accepted at the tariff level
it is conveyed to the cargo system (in a non-Line
Release scenario). The information is sent to
DOT/NHTSA.
When the cargo has already been released via a Line
Release mechanism (e.g., FAST), the DOT/NHTSA
form HS-7 information is required (or may be
disclaimed) based on the HTS requirement. The
information is sent to DOT/NHTSA.
(J10) How a Census ‘warning’
condition is overridden:
All legitimate Census warning ‘conditions’ are overridden
manually (by the trade participant or by CBP).
(J11) How a ‘documents required’ or
‘paperless’ notification is initially
returned to the Filer:
An indication of ‘documents required’ or ‘paperless’ is
returned as part of the Narrative Message text in the E0Record as part of the ER response.
(J12) How an Entry Summary can be
corrected (through an unsolicited
submission) once it has been paid:
Historically, a Post Entry Amendment (PEA) could be
presented.
2/8/2016
ACE (AE/AX)
Full Entry Summary support of DOT/NHTSA form data
submission:
ACE ABI CATAIR

A DOT/NHTSA form HS-7 (or disclaimer) submission
at the tariff level will ONLY be accepted when Cargo
Release Certification has been requested. ACE will
forward the DOT/NHTSA information to ACS for the
‘cargo certification’ process (including the validation
of the data).
The Entry Summary shall fatally reject when the
cargo has been released via a Line Release
mechanism and any tariff requires or may require
DOT/NHTSA data. This type of Entry Summary must
be submitted in ACS (using the EI transaction).
(Note: An Entry Summary that correlates to a Line
Release that does NOT have any DOT/NHTSA concerns
may be submitted into ACE using the AE transaction.)
Filer may preemptively override up to seven Census
warnings at the line level (using the CW02-Record).
(Note: The warnings may arise at the tariff level, yet are
to be overridden at the line level.)
 There shall be no indication as the requirement to
submit paper; the filing is assumed to be ‘paperless’
until such time that CBP deems otherwise. The AX
response shall indicate only if the Entry Summary data
has been accepted or rejected.
 A subsequent message (transaction UC) will be sent
to the Filer when documents are required (if needed).
The UC transaction is a general purpose notification
mechanism.
The Entry Summary can be replaced with a Post
Summary Correction. A PEA is not allowed for an ACE
Entry Summary.
Page 15 of 15