ISF Filing Software

ISF filing software prepares and transmits the Importer Security Filing, known as 10+2, that CBP requires for ocean shipments bound for the United States. The rule requires the filing at least 24 hours before the cargo is laden aboard the vessel at the foreign port, and it must carry ten data elements the importer owes plus two the carrier provides. Captain assembles those elements from your purchase orders, item master, and booking, tracks the lading deadline, transmits through AMS, and captures the CBP response. The result is that the ISF is complete and on record before the vessel sails, rather than a manual filing that races the cutoff and sometimes triggers penalties for being late or wrong.

They cover two different customs events. ISF filing happens before the goods sail, at least 24 hours before lading, and its purpose is advance cargo security data, not duty. Customs clearance, or entry filing, happens as the goods arrive in the US and is where classification, valuation, and duty are declared to release the cargo. The ISF is the early gate; the entry is the arrival gate. In Captain both run on one platform, so the party, origin, and HTS data captured for the ISF carries forward into the entry rather than being re-keyed. If your question is filing the advance security data on time, that is this module; declaring the entry to clear customs is the clearance module it feeds.

The importer owes ten elements: manufacturer or supplier, seller, buyer, ship-to party, container stuffing location, consolidator, importer of record number, consignee number, country of origin, and the HTS number of the goods. The carrier provides two: the vessel stow plan and container status messages. Captain pulls the importer elements from the systems that already hold them, purchasing for the trade parties, the item master for origin and HTS, the booking for stuffing and consolidation, so the filing is built from live data rather than typed from an email. Two of the ten elements have flexible timing and can be updated as they firm up, and the platform handles those updates so the initial filing is not held up waiting for late details.

The core risk with an ISF is the 24-hour-before-lading deadline, and a filing that misses it exposes the importer to liquidated damages. The platform tracks that clock against the vessel schedule for each shipment and raises escalating alerts as the cutoff approaches, and it warns when an element is still missing so you know what is blocking the filing rather than discovering the gap at the deadline. At-risk shipments collect in a queue with their exposure attached, so the import team works the ones in danger first. The point is to surface the timing problem early enough to act, instead of finding out the ISF was late when CBP issues the penalty.

CBP can assess liquidated damages of up to 5,000 dollars per violation for an ISF that is late, inaccurate, or incomplete, and repeated problems draw closer scrutiny and can slow your cargo. Because the penalty is per filing, a systemic timing or data problem multiplies quickly across a high-volume importer. The software is built to design that risk out: it assembles complete data, enforces the deadline with alerts, validates elements before transmission, and captures the CBP acceptance so a rejection is caught and corrected before sailing rather than after. Keeping timeliness and accuracy high is not a nicety here, it is the direct control on a recurring, quantifiable penalty.

Yes. The filing is transmitted electronically to CBP through AMS, the Automated Manifest System channel used for ISF, and the platform captures the response, whether the filing is accepted or returned with errors. A rejection is surfaced immediately with the reason, so it can be corrected and refiled while there is still time before lading, rather than sitting unnoticed until the cargo is already at sea. Capturing the acceptance is also what gives you provable timeliness: the record shows exactly when the ISF was transmitted and accepted relative to the vessel lading time, which is the evidence CBP wants if timeliness is ever questioned.

Yes. An ISF must be covered by a bond, either your continuous customs bond or a single-transaction ISF bond, and the platform links the correct bond to each filing and checks that coverage is in place before transmission. It carries the importer of record and party details and validates them, so a filing is not transmitted with a bond or party gap that could cause a rejection or a coverage problem. For importers running a continuous bond, this ensures every ISF draws on valid coverage; for occasional importers using single-transaction bonds, it keeps the right bond attached to the right filing so nothing files uncovered.

Yes. Some ISF elements are known only close to lading or can change before the goods arrive, and the rule allows updates. The platform lets you update elements as they firm up and keeps a full amendment history, so the filing stays accurate through to arrival and you have a record of what changed and when. Two of the ten importer elements carry flexible timing, and the software handles those so an initial filing is not blocked waiting for details that are allowed to come later. Tracking amendments matters because accuracy is judged on the filing as it stood, so a clean history of updates supports your compliance if a discrepancy is ever raised.

Yes. The platform connects to your ERP, purchasing system, item master, and carrier feeds through API integration, so the importer elements come from purchasing and the item master and the carrier elements come from the booking, all without manual re-keying. This is what makes on-time filing realistic at volume: the data assembles itself from the systems that already hold it, and the import team confirms and files rather than hunting for elements shipment by shipment. Because the filing lives on the shared platform, its data also carries forward into the customs entry and into brokerage, so nothing captured for the ISF has to be re-entered downstream.

The ISF and the entry are separate filings at separate times, but they share a lot of data: the parties, the country of origin, and the HTS numbers appear in both. Filing them on one platform means the data captured for the ISF before lading carries forward into the entry filed on arrival, so it is entered once and reused rather than re-keyed, and discrepancies between the two filings, which CBP notices, are avoided. The entry itself runs in the customs clearance module, which picks up from the ISF record. Keeping both on the same dataset is how you keep the advance filing and the arrival filing consistent instead of maintaining them as two disconnected processes.

A typical rollout can be live in about two to three weeks. The main work is mapping each of the ten importer elements to its source field in your purchasing and item-master data and confirming the carrier feed for the two carrier elements, then linking bonds and setting deadline alert lead times and escalation rules. Once the element mapping is validated against a sample of real shipments, filing goes live. Importers with clean, well-structured purchasing data and a single carrier integration move fastest; many trade parties, multiple carriers, or sparse origin and HTS data extend the mapping work. As elsewhere on the platform, data quality at the source is the usual gate.