Export Compliance & Documentation

The contract says CIF, the invoice was changed to FOB at the customer's request, and the declaration was filled in as CIF out of habit. Each document is internally consistent. Together they are a rejection.

This is not a skills problem. The document set is assembled by different people at different times from different sources: sales writes the contract, finance writes the invoice, the broker files the declaration, the forwarder issues the bill of lading, and the certificate of origin comes from yet another window. Nobody owns the question 'do these agree?'

1. The list lives in someone's head. Which documents a given destination needs is tribal knowledge; a new market means starting from trial and error.
2. The same fact typed repeatedly. Product description, specification, terms, currency and quantity are re-entered in four or five files — every entry is a chance to differ.
3. Completeness is invisible. The container is about to load and the certificate of origin has not been applied for. Either the sailing date or the documents move, and both cost money.
4. Rejection reasons are not recorded. The shipment is fixed and the reason is forgotten, so the same error returns next month.
5. Archives are scattered. An audit or a customer verification means assembling files from mailboxes, shared drives and personal folders by order number.

The design response is to stop treating the document set as many files and treat it as one set derived from a single locked group of elements. Enter the elements once; generate the documents from them; make completeness a live state; record rejections by field.

The larger gain is not the lower rejection rate. It is that a destination's document list becomes reusable: the country pack holds which documents that market requires and which fields matter, so a salesperson moving to a new market does not start from zero.

Note what the last row really is. The declaration does not create inconsistencies; it exposes them. That is why 'reduce rejections' cannot be solved at the declaration — it has to be solved in the five documents upstream.

The element set is the centre of this line: terms of trade, currency, product description and specification, quantity and amount, consignor and consignee, destination. All documents are generated from it. Changing an element leaves a trace and re-issues the dependent documents — a single file may not be edited in isolation.

Each document then carries a state: not generated, generated, issued, verified. If one is missing, the shipment's state is 'incomplete', and that state is the gate before loading.

The rejection library is the part teams skip and later wish they had. Record every rejection by document, field, counterpart file, owner and time to resolve. After six months, the concentration is obvious — and the two or three field pairs that keep failing are exactly the ones that should be mandatory validations.

Two hard rules. Every download carries a watermark and an audit entry — who, when, which version. And a portal account can only download issued documents belonging to its own orders: unissued and other customers' files are excluded. The second rule is what keeps a customer list from becoming a competitor's.

1. Typing one fact into several documents. That is the origin of every inconsistency. One entry, everything else derived, is the only structural fix.
2. Allowing a single document to be edited alone. The invoice changed and the declaration did not — that is a rejection. A change must create a version and re-issue dependants.
3. Counting completeness at month end. Discovering the missing certificate of origin when the container is due to load means moving a sailing date or a document, and both cost money.
4. Treating industry practice as the filing rule. Industry commentary describes what usually works and what usually gets rejected. Where it conflicts with the published rule, the rule wins.
5. Not recording rejection reasons. The same error recurs because nobody knows which field failed. The rejection library is the only basis for process improvement.
6. Writing a destination's document list into the main flow. Lists differ per country and change over time. The list belongs in the country pack; the flow stays the same.

Mechanism problems make errors happen reliably. Judgement problems make them impossible to correct, because they look like 'this is how everyone does it' — which is precisely the state in which nobody goes looking.

For each one: which document, which field, inconsistent with which other file. Most teams find the problems concentrated in two or three field pairs — and those are exactly the pairs that should become mandatory validations.

1. Classify the last ten rejections by document, field and counterpart document.
2. Count how many times the same fact is typed into separate files today.
3. Check whether completeness is a live state or a manual review before loading.
4. Walk through element derivation and the completeness gate in the demo environment.
5. For a specific market's document list, read the corresponding country pack.

• Vehicle export trading
• Cross-border logistics & in-transit
• Export finance & settlement