How to File ISF 10+2 via EDI 309 in ACE

What You Need Before You Start

Filing an ISF through EDI 309 isn't something you set up from scratch in an afternoon, and most teams shouldn't try. Before you touch a translator or a trade-compliance UI, confirm four things are in place.

• An active ABI filer relationship. That means you're a self-filing importer with CBP-approved ABI software, a licensed customs broker, or an NVOCC with an ISF transaction code already issued by CBP.
• A bond that actually covers ISF. The ISF Importer, or its agent, must denote the usage of the Appendix D stand-alone single transaction ISF bond on the ISF by identifying bond activity code 16, bond type 9 (single transaction), the valid surety code and the bond reference number, or you're covered under a continuous bond that includes ISF activity.
• An EDI translator or trade-compliance platform that can generate X12 005040 "SF" functional group interchanges. Very few teams hand-build 309 segments in production. In practice you're populating Descartes CustomsInfo, e2open's trade compliance module, Thomson Reuters ONESOURCE Global Trade, or Integration Point, and letting the platform generate the ABI transmission. Knowing the underlying EDI still matters, because when a filing rejects, you're the one debugging the mapping, not the vendor's support desk.
• The carrier or NVOCC's ACE Ocean eManifest bill of lading number already booked. This is the field that trips up more filers than any data element on the ISF itself, and we'll come back to it in Step 4.

One more thing worth knowing going in: all filings need to be electronically submitted through either the Automated Broker Interface (ABI) or CBP's Automated Commercial Environment (ACE). There's no paper fallback, and there's no "email the broker a PDF" option that satisfies the regulation.

Step 1: Confirm the Shipment Actually Needs an ISF

ISF applies to ocean cargo, not every mode, and not every ISF is the same type. Get this wrong and you file the wrong submission type, which generates its own rejection.

The Importer Security Filing needs to be submitted for all ocean cargo destined to the United States, with manifest information submitted 24 hours before the cargo is loaded on the vessel for containerized cargo, while authorized break-bulk cargo needs to be submitted 24 hours before arrival. Bulk cargo does not need an ISF submitted. Air, truck, and rail shipments fall outside ISF entirely.

1. Full container load or LCL ocean cargo — files as ISF-10, the standard "10+2" submission.
2. FROB, immediate exportation, or transportation-in-bond shipments — these get the simplified ISF-5. For US import shipments the ISF needs ten (10) data elements, while for in-transit, FROB, T&E or IE bonds the ISF needs to have five (5) data elements.
3. Break-bulk cargo not on the authorized carrier/commodity list — treated as standard ISF-10 on the 24-hour-before-loading clock.
4. Bulk cargo (grain, ore, liquid bulk) — exempt, no filing required.

Picking the wrong type here is a real failure mode in its own right. If you submit an ISF-5 for a shipment that should have been filed as ISF-10, you'll need to replace it, and there's a dedicated submission type code for exactly that scenario in the CATAIR.

Step 2: Collect the 10+2 Data Elements

The ten importer-side elements have to be in hand (or flagged for Flexible Timing) before you build the transaction. Importers are expected to provide 10 data elements on their Importer Security Filing: Buyer, Seller, the Importer of Record (IOR) number or Foreign Trade Zone (FTZ) applicant number, Consignee identification, the six-digit U.S. HTS code, Manufacturer or supplier, Ship to party, Country of origin, Container stuffing location, and Consolidator. Carrier provided elements include the vessel stow plan and container status messages — the "+2" that never touches your 309 filing because the ocean carrier transmits them separately.

Two fields cause more errors than the other eight combined:

• Importer of Record Number. This has to be a valid, active EIN, SSN, or CBP-assigned number, and in a Unified Entry/ISF filing, the Importer of Record for Entry purposes and the ISF Importer must be the same entity, with the same Importer of Record Number. A typo or a stale EIN here doesn't just reject the ISF, it can orphan the link to the entry.
• Country of Origin. This is the country of manufacture or substantial transformation, not the country of export. This is NOT the country of export — goods assembled in Vietnam from Chinese components may require a country-of-origin analysis, and country of origin determines which tariff rates apply, including Section 301 duties. Get this wrong and you're not just risking an ISF rejection, you're risking a duty determination problem downstream.

If you don't have everything yet, CBP built flexibility into the rule on purpose. Flexible Timing lets you submit without the consolidator and stuffing location initially, and Flexible Range lets you submit best-known data for manufacturer, ship-to, country of origin, and HTS. Either way, the party that files the Importer Security Filing is required to update the ISF in the case of any changes in the submission and before the merchandise arrives at a US port, including providing more precise information if it becomes available.

Step 3: Build the X12 309 Interchange

The 309 is CBP's purpose-built transaction set for ISF, not a repurposed EDI standard. This X12 Transaction Set contains the format and establishes the data contents of the U.S. Customs and Border Protection Stand Alone Security Filing using the 309 transaction set, intended for use within the context of an Electronic Data Interchange environment, and can be used by carriers, NVOCCs, brokers and/or third party contractors submitting on behalf of importers.

The segment skeleton you're debugging against, if a translator mapping goes sideways, looks like this:

• ISA/GS/ST header. GS01 is always 'SF' — Stand Alone Security Filing (ISF-10 or ISF-5). The 'SF' Functional Group identifier should be used exclusively for Stand Alone ISF Filings, under the ASC X12 005040 release.
• M1009 Manifest Type Code. A required field that carries the ISF Submission Type Code — this is where ISF-10 vs. ISF-5 gets declared at the EDI level, and where a mismatch with Step 1's decision produces a reject.
• SF10 record. A mandatory record that provides the ISF Importer number to which the ISF submission is related. Everything else in the filing hangs off this.
• Entity segments for each data element. When an ISF-10 submission type is used, the SF data set must have a segment for each of the following Entity Codes: MF, SE, BY, ST, CS, CN, and LG — Manufacturer, Seller, Buyer, Ship-to, Container Stuffing location, Consignee, and the IOR/FTZ Legal entity. For ISF-5, the entity codes narrow down to BKP (Booking Party) and ST.
• NM1 segments for importer identity. One NM1 segment is required to report the ISF Importer for all transactions, and a second NM1 segment is required to report the Importer of record when the submission type is ISF-10.

Most EDI teams never hand-build this file. You're populating a UI or calling an API on Descartes, e2open, ONESOURCE, or Integration Point, and the platform generates the 309 transaction on your behalf. The value of knowing this layout isn't that you'll write it by hand — it's that when your translator throws a mapping exception or your broker's system kicks back an unexplained error, you can open the CATAIR spec, find the segment, and tell the difference between "our data is wrong" and "the platform's mapping is wrong." Those are very different support tickets.

Step 4: Transmit via ABI and Link to the Bill of Lading

Submission timing and bill-of-lading level matter as much as the data itself. ISFs are to be submitted at the "lowest" bill of lading level that was submitted in ACE Ocean — Master, Regular, or House, whichever is the most granular bill registered in the Ocean eManifest for that shipment.

Here's the part that causes the most pain in production: the bill of lading or Cargo Control Number forms the link between the ISF and the ACE Ocean eManifest. CBP's system doesn't fuzzy-match. If your ISF carries a bill number formatted with a space, a different prefix, or a truncated SCAC, and the carrier's eManifest has the "real" version, the two records never join. This is a formatting problem more often than a data problem, and it's the single most common ISF rejection reason EDI teams run into.

Qualifier codes matter here too. Valid qualifier codes are OB for ocean bill of lading used for regular bills, and BM for house bill of lading, and a master bill of lading will always have underlying house bills. Confirm with the carrier or NVOCC which bill number and qualifier they used on their ACE Ocean eManifest submission before you transmit, not after you get a reject.

Step 5: Read the 355 Response and Confirm Acceptance

CBP's answer to your 309 comes back as a 355, and reading it correctly is how you know the filing actually worked. This X12 Transaction Set contains the format and establishes the data contents of the U.S. Customs Acceptance/Rejection Transaction Set (355) for use within an EDI environment, used by U.S. Customs to report errors and discrepancies discovered in the U.S. Customs transaction sets, and the 355 message is returned in response to the inbound 309 message.

A clean acceptance shows a few consistent markers:

1. The ISF transaction number from CBP is present and recorded — after CBP has received and accepted the ISF, the ISF filer will receive a unique ISF transaction number from CBP. Save this number; you'll need it for any later amendment.
2. No K1 remarks segments flagging errors. If CBP found a problem, when one or more errors are determined as a result of processing a given transaction, each segment in-error is flagged, and all error messages found in the K1 segments are explained in the CAMIR Appendix H.
3. In ACE or your broker's response queue, status reads "Filed/Accepted" rather than pending or rejected, and ISF status becomes "Accepted" once CBP has processed it clean.
4. Later, at entry, the system confirms the match: CBP releases the shipment or issues an exam order, and the ISF is "matched" to the entry in CBP's ACE system — unmatched ISFs generate compliance flags.

If instead you get a rejection, don't assume the whole filing is void. The 355 tells you exactly which segment and element failed. Fix that element, resubmit, and watch for the acceptance on the next cycle.

Step 6: Handle the Most Common Failure Mode — Bill-of-Lading Mismatch

This is the rejection you'll see more than any other, and it's almost always a formatting problem between what your ISF carries and what the carrier's ACE Ocean eManifest has on file.

The fix isn't to file a brand-new ISF. The transaction set identifier for this input set is SF, and the response from CBP will be in the SN output transaction set; to delete a previously accepted Importer Security Filing, only the SF10 record is required, containing the ISF transaction number previously provided in the SN output transaction. In practice:

1. Pull the original acceptance (355/SN) and confirm the ISF transaction number you were issued.
2. Call or message the carrier/NVOCC to get the exact bill of lading number and qualifier (OB or BM) as it sits in their Ocean eManifest record — character for character, including any leading zeroes or SCAC formatting.
3. Correct the bill of lading field in your source system and resubmit as a Replace transaction against the existing ISF transaction number, not a new Add. This avoids triggering a duplicate-filing reject on top of the original mismatch.
4. Confirm the corrected 355 comes back clean before the vessel loads, since the clock doesn't stop for you to fix it.

Missing that fix costs real money. Failure to comply with the ISF requirements can result in liquidated damages of $5,000 per violation, and that's per bill of lading, not per shipment — a consolidated shipment with multiple house bills and multiple unresolved mismatches can turn into a five-figure exposure fast. There's also a non-monetary cost: an unmatched or rejected ISF close to vessel loading can trigger a "do not load" instruction from CBP, which is a conversation with your customer you'd rather not have.

Where This Fits Into Your Broader EDI/TMS Stack

ISF filing is the first customs touchpoint in a much longer document chain, not the last. Once the 355 comes back accepted, the same shipment reference data (bill of lading, container number, PO) flows into carrier booking confirmations, the 856 ASN and 210 freight invoice cycle on arrival, and whatever platform orchestrates visibility from vessel departure to warehouse receipt.

This is also where ISF compliance software and transport execution software tend to split into two separate systems that still need to agree on the same reference numbers. Your trade-compliance platform (Descartes, e2open, ONESOURCE) owns the ABI/ACE filing relationship. A transport management or visibility platform like Cargoson, MercuryGate, or Uber Freight picks up execution and tracking once customs clears the shipment. If the bill of lading format isn't consistent across both systems, the same mismatch problem from Step 6 reappears downstream in your TMS reconciliation, just with a different symptom. Build the mapping once, enforce it at the point of booking, and you won't be chasing the same bill-of-lading formatting bug in two different systems at two different stages of the shipment lifecycle.