At the same time, any technical mistake poses a risk of duty underpayments, fines for the client, and lengthy cargo delays at the customs control stage.
| Technical challenge | Broker's reality |
|---|---|
| Document reconciliation | Different file formats: PDF, Excel, jpeg etc. |
| Currency control | Invoice in $, transportation in €, accounting in GEL |
| Weight balance | Net/gross distribution by line items |
Where Time is Lost: Anatomy of Handling a Complex Shipment
Let's consider a standard task: an import invoice containing 40–50 mixed items (e.g., auto parts, electronics, or construction materials). It is accompanied by a packing list and a CMR.
Here is what the actual data preparation process looks like before the "Submit" button is pressed:
1. Consolidating Disparate Data into a Working Matrix
Documents from the client arrive in a chaotic manner: the invoice in a locked PDF, the packing list in Excel with a different row structure, and the CMR as a copy from a messenger app. The broker needs to do more than just rekey numbers; they must match them. It is necessary to manually correlate the commercial description from the invoice with the specific net/gross weight and number of packages from the packing list for each of the 40 items. This mechanical window-switching and copying takes up to 60–90 minutes.
2. Multi-Currency Calculations and National Bank Exchange Rates
Rarely does a shipment go without a calculator. Often, the invoice itself is issued in US dollars or Euros, the freight and insurance costs are stated in the international consignment note as a lump sum in another currency, while the customs value for ASYCUDA must be calculated strictly in Georgian Lari (GEL) at the official exchange rate of the National Bank of Georgia on the day of declaration. The broker manually writes proportion formulas in Excel, recalculates cross-rates for each line, and adjusts rounding errors down to the tetri so that the total sum matches perfectly.
3. Legal Responsibility and HS Code History
Selecting HS codes is not just a matter of searching through a directory of 13,700+ entries. It is a zone of personal legal liability for the broker. A code error results in accusations of duty underpayment or incorrect declaration. An experienced specialist does not trust random databases; they check their own filing history for the specific client and counterparty. Manually searching through past declarations and archives to recall which code allowed this product to pass customs smoothly last time consumes precious time.
4. Final Validation Prior to Import
Before uploading the completed SAD XML file into ASYCUDA World, the broker double-checks the gross and net weight balance, the country of origin codes, and the total amounts. A mistake in a single digit is guaranteed to block the file submission or trigger internal system errors that require a full data re-check.
Three Critical Points That Excel Macros Cannot Fix
- Net and Gross Weight Discrepancies If the total pallet weight in the packing list is distributed across line items incorrectly, or if a rounding error occurs, the system will reject it. Reconciling this data manually costs a huge amount of time and resources.
- Changes in Customs Regimes and Preferences The exact same product coming under different contracts (e.g., with or without a EUR.1 certificate) requires a different approach to duty calculations. Excel cannot automatically pull the terms of Georgia's free trade agreements with other nations.
- Loss of the Accumulated Knowledge Base If different brokers within the same company work on a client's account, they have to constantly ask each other about the logistics and logic of past filings.
How We at METI Approach Process Automation
We understand that ASYCUDA World is a given, and a broker cannot alter its rules. However, the entire routine chaos occurring before the program is opened can be automated.
That is exactly what we do. Our product, Declarant, is not created to replace a broker's expertise, but to remove the data-entry operator role from their job description: document recognition, multi-currency recalculation using National Bank rates, freight distribution across items, and SAD XML generation for import into ASYCUDA.
We Are Looking for Technology Partners, Not Users
Declarant is currently under active development. We have already trained the algorithms in basic recognition and tested the calculation logic on mock-ups of complex invoice and transport documentation. Now we need to take the next step — testing the system under field conditions.
We are not offering a ready-made "out-of-the-box" solution. We are looking for brokerage firms willing to participate in shaping the product: to test the automation alongside us using your past or current documents, point out algorithmic flaws, and help shape requirements tailored to your internal workflows.
This is not "free access" in exchange for loyalty. This is collaborative work: you invest your time and expertise — we adapt the algorithms to your document formats and operational schemes.
If you handle dozens of declarations per week and understand exactly where time is being lost, we have something to talk about.