Pre-alerts: the same data re-keyed in every system
The pre-alert arrives as a PDF and the same fields get re-keyed into the ERP, CE Mercante and DUIMP. Each re-entry is another chance for an error to propagate.
The bill of lading number for a single ocean import gets typed at least three times before the container leaves the terminal. Once into the forwarder’s ERP, once into CE Mercante inside Siscomex (Brazil’s customs cargo system), once into the DUIMP preparation (Brazil’s single import declaration). Consignee, shipper, gross weight, container number, cargo description, HS code: they all follow the same route. The data starts in a pre-alert PDF attached to an email from the overseas agent. The operator reads it and types it. Then types it again somewhere else.
The pre-alert is where almost every data point originates. It carries copies of the B/L, commercial invoice and packing list, plus the vessel name, departure date and estimated arrival. The operator uses those documents to open the job in the ERP, register the CE in Mercante and hand the data to the customs broker for the declaration. At each step, someone reads the same PDF and types the same fields into a different screen. A forwarder handling 150 ocean imports per month goes through this cycle 150 times, with eight to twelve fields per cycle showing up in more than one system.
The same field appears in three different systems
The operator receives the pre-alert and opens a new job in the ERP. They type the B/L number, vessel name, sailing date, port of loading, port of discharge, consignee, shipper, number of packages, gross weight and each container number. Some of those fields come from the B/L copy, some from the commercial invoice, some from the packing list. While filling in the screen, the operator mentally cross-checks all three documents. The weight on the B/L might not match the packing list. The description on the invoice might not match the B/L.
After the ERP entry, the same operator (or a colleague) opens Siscomex Mercante and registers the CE (Brazil’s electronic cargo manifest). CE Mercante asks for the B/L number, consignee tax ID, cargo description, weight, package count and container number. Same fields, same PDF, typed again. Brazil’s Federal Revenue Service requires CE Mercante data to match the bill of lading exactly, and any discrepancy flagged during customs screening triggers a formal inquiry.
From there the data goes to the customs broker, who prepares the DUIMP. Because Siscomex Carga integrates with the DUIMP, some CE Mercante fields auto-populate the declaration. Gross weight, consignee, description, container number: they migrate from the CE to the DUIMP with no one retyping them. If the CE is right, this saves time. If the CE has a typo, the DUIMP inherits it, and the broker may not notice until customs screening flags the mismatch.
A CE Mercante error propagates into the DUIMP
The integration between Siscomex Carga and the DUIMP, documented in the Portal Unico Siscomex manuals, was built to eliminate re-keying. In practice it works as a multiplier. A correct entry saves time on both sides; a wrong entry spreads to both sides. If the operator types 12,500 kg in CE Mercante and the packing list says 12,850 kg, that 350 kg gap lands in the DUIMP untouched. No one retypes the field because it arrived pre-filled.
Rectifying a CE Mercante entry, as we covered in a previous post on the topic, has a deadline and a cost. If the discrepancy shows up before berthing, the consolidator has up to 48 hours before the vessel’s arrival to correct it. After that window, the correction requires a formal request and may trigger a fine. For the operator who typed the wrong weight, it is one more task in a queue that never gets shorter.
Things get harder when the pre-alert itself arrives incomplete or inconsistent. The overseas agent does not always send the final B/L. Often the pre-alert carries a draft, and the definitive version shows up days later. An operator who registers CE Mercante off a draft risks entering data that will change. When the final version arrives with a different consignee or a corrected weight, the operator has to rectify the CE and check whether the DUIMP already pulled the old data.
Checking the pre-alert against the B/L takes longer than typing it
The operator’s real work with the pre-alert is not the typing. It is the cross-check. Comparing the B/L weight against the packing list weight. Checking that the cargo description on the commercial invoice matches the one on the B/L. Making sure the container number is consistent across all three documents. This reconciliation happens in the operator’s head, one document at a time, one line at a time.
Nobody can hold that level of attention across 30 pre-alerts in a day. The first few checks are careful. By the fifteenth, repetition and volume have worn the operator down, and the checks get faster and sloppier. The error that slips through becomes a CE Mercante rectification, a DUIMP inquiry, or a cost the forwarder eats after the container has already left the terminal. We described this same dynamic in import document checking: manual cross-checking holds up at low volume and falls apart as volume grows.
In our experience working with freight forwarders in Brazil, pre-alert processing is where operators spend more time than on any other step in the import workflow. Receive, open, cross-check, type, cross-check again, fix what slipped through. Each ocean import job takes between 15 and 40 minutes just to get the pre-alert data into the ERP and CE Mercante without errors. At 150 jobs per month, that is between 37 and 100 hours spent moving data from a PDF into systems that do not talk to each other.
How Autodocs reads the pre-alert before anyone opens the file
Autodocs receives the pre-alert by email or API, classifies each attached document (B/L, commercial invoice, packing list) and extracts every field along with a confidence score and the source page. Before any record is created, the validator library checks the container number against the ISO 6346 check digit, the port against UN/LOCODE, the currency against ISO 4217, and compares weight and package counts across documents. Fields the system is unsure about go to the operator for review. Fields that pass validation enter Tier2 Cargo as a ready record, already filled in.
A field that today gets typed three times gets typed zero times when extraction is confident, and once when extraction flags a doubt. The operator’s job shifts from reading and typing PDFs to reviewing what the system already extracted and correcting the few values that fell below the confidence threshold.
Ready to transform your operations?
Discover how Tier2 Systems can help your company with intelligent ERP, AI agents, and automation built from real-world experience.
Learn How We Can Help