ACE ITN Validation: October 2026 DIS Changes

ACE ITN validation will introduce a consequential control for exporters, AES filers, and customs brokers submitting EEI-related documents through the Document Image System. Beginning October 8, 2026, an inaccurate or improperly formatted Internal Transaction Number can cause the entire DIS submission to be rejected rather than accepted for review.

What Changes With ACE ITN Validation

The CBP-255 enhancement is scheduled to enter the ACE production environment on October 8, 2026, following deployment in the certification environment. Once active in production, ACE will validate an Internal Transaction Number whenever an ITN is supplied with an EEI-related Document Image System submission.

Validation applies whether documents are transmitted through Electronic Data Interchange or submitted to DIS by email. That scope matters because organizations cannot avoid the control by switching submission channels. Any workflow that supplies an ITN must produce a valid number in the exact format associated with the corresponding Automated Export System transaction.

Rejections Replace Manual Error Recovery

If ACE determines that an ITN is invalid or that its format is incorrect, the system will return the message: “Submitted ITN is invalid or the format is invalid.” The DIS submission will be rejected.

This outcome changes the operational significance of ITN data quality. A typo, omitted character, altered prefix, added space, or value copied from the wrong AES transaction may prevent the supporting documents from reaching the intended review process. Depending on shipment timing and the documents involved, a rejected package could contribute to export processing delays and additional coordination among exporters, forwarders, brokers, carriers, and internal compliance teams.

The control does not merely assess whether an entry looks like an ITN. It requires a valid matching ITN already associated with the relevant AES export transaction. Filers should therefore treat the ITN as a controlled transaction identifier rather than free-form reference data. Accuracy must be verified at the source before the DIS package is transmitted.

Why Exact ITN Matching Matters

An ITN is generally generated after an Electronic Export Information filing has been accepted in AES. It serves as evidence that the export transaction has been filed and accepted, subject to the circumstances and requirements applicable to the shipment. Organizations commonly reuse that identifier in downstream documentation, vehicle export processes, carrier communications, and DIS submissions.

The risk arises when the ITN passes through multiple systems or teams. Manual rekeying, spreadsheet exports, email forwarding, optical character recognition, and copy-and-paste procedures can introduce subtle discrepancies. A value may remain recognizable to a person while failing automated validation.

The AES Transaction Should Be the System of Record

The safest practice is to retrieve the ITN directly from the accepted AES transaction and preserve the exact format. Filers should not reconstruct the number from memory, remove characters for presentation purposes, or substitute an internal shipment reference.

Common control weaknesses may include:

• Using an ITN from a previous filing for the same exporter or vehicle
• Transposing digits during manual entry
• Adding spaces, punctuation, or descriptive text to the ITN field
• Removing part of the identifier because another system applies field-length limits
• Submitting documents before AES acceptance has produced a valid ITN
• Reusing an earlier ITN after an EEI filing has been corrected or replaced
• Pulling the identifier from an email subject line instead of the accepted AES record

Organizations should also distinguish ITN validation from broader EEI accuracy. A successful match indicates that the submitted identifier is valid and properly formatted. It does not necessarily confirm that every data element in the underlying EEI filing is correct, that all required documents have been supplied, or that the export satisfies every applicable compliance obligation.

An Operational Readiness Checklist for October 8

Export teams should use the production date as a firm deadline for testing data flows and clarifying ownership. The most effective preparation focuses on how an accepted AES transaction becomes linked to a DIS document package, including every manual and automated step between those events.

Map and Test the Submission Workflow

A practical readiness review should include the following actions:

1. Inventory affected submissions. Identify every business process that sends EEI-related documents to DIS and supplies an ITN, whether through EDI or email.
2. Locate the authoritative ITN. Document where the accepted AES-generated identifier is stored and which system or team provides it to the DIS workflow.
3. Compare the value character by character. Confirm that the DIS submission uses the exact ITN from the corresponding AES transaction, without spaces, labels, truncation, or reformatting.
4. Test EDI mapping. Review source fields, transformations, field lengths, and outbound message construction. Certification testing should include valid values as well as intentionally malformed or mismatched values.
5. Standardize email procedures. Where documents are submitted by email, use a controlled template and prohibit staff from manually reconstructing the identifier.
6. Define rejection ownership. Assign responsibility for monitoring responses, researching the AES record, correcting the package, and resubmitting documents.
7. Retain an audit trail. Preserve the accepted AES record, transmitted ITN, DIS package, rejection message, correction, and final submission outcome.

Build Controls Around Exceptions

A rejected package should trigger a structured exception process rather than repeated attempts with guessed values. The responsible team should first confirm that the ITN exists in AES, belongs to the correct transaction, and has been copied in its original format. If the AES filing itself requires correction, that issue should generally be resolved before the document package is retransmitted.

Trade compliance leaders should also review service-level expectations with third-party filers and logistics providers. Contracts and operating procedures should identify who validates the ITN, who receives ACE responses, and how quickly rejected submissions must be escalated. Questions specifically concerning ITN validation may be directed to cbpvehicleexports@cbp.dhs.gov.

Frequently Asked Questions

When Does ACE ITN Validation Begin in Production?

The CBP-255 enhancement is scheduled for production deployment on October 8, 2026. Exporters, AES filers, and brokers should complete workflow reviews and testing before that date. The enhancement has already been made available in the ACE certification environment for testing.

Which DIS Submission Methods Are Affected?

Validation applies when an ITN is provided through an EDI transmission or with a DIS submission made by email. Organizations should review both channels, even if one is used only as a backup or for a limited category of export documents.

What Happens When the ITN Is Invalid?

ACE will reject the DIS submission and return the message: “Submitted ITN is invalid or the format is invalid.” The filer must investigate the discrepancy, confirm the correct identifier from the corresponding AES transaction, and resubmit the document package with a valid, properly formatted ITN.

Does a Valid ITN Confirm That the EEI Filing Is Correct?

Not necessarily. ITN validation confirms that the supplied identifier is valid, properly formatted, and matched to an ITN on file. It generally does not replace substantive review of the EEI filing, document package, export classification, licensing status, party data, or other applicable compliance requirements.

Can a Filer Reformat the ITN to Match an Internal System?

Filers should avoid changing the identifier. The ITN in the DIS submission should match exactly what was provided for the corresponding AES export transaction. Internal systems that truncate, reformat, or append text to the value should be corrected before production deployment.

How Stable Software Can Help

Supporting Broker-Led Compliance Services

ITN validation illustrates why customs brokers need disciplined data controls, clear exception ownership, and dependable client-facing workflows. Stable Software supports broker-led trade operations through DrawbackAI, flat-license duty drawback software that U.S. customs brokers can white-label for importer clients while filing under their own filer code.

Stable Software charges a flat software license and never takes a percentage of the importer’s refund. Although DrawbackAI is focused on duty drawback rather than EEI or DIS filing, the model gives brokers a practical way to expand technology-enabled compliance services while retaining control of client relationships and filings. Customs brokers evaluating software for their importer service portfolios can learn more on the Stable Software broker page.

Resources