Planning a new product or business system? Get a free consultation.Free consultation for your next build. Contact us
DIGITAL TRADE / INTEROPERABILITY / 31 October 2026

Cross-Border Trade Still Runs on Systems That Disagree About the Same Transaction

A shipment, an invoice, a payment and a customs declaration can describe the same trade in incompatible ways. Digitising each document separately does not fix the disagreement.

Cargo ships and containers at port
Photo by PortCalls Asia on Unsplash.

The observation

The Internet has made it easy for a business to discover a supplier across the world. It has not made all of the records behind that transaction agree. A supplier can issue an invoice, a buyer can authorize payment, a logistics provider can register a shipment and customs can receive a declaration. Each system may be functioning correctly on its own terms while describing the same trade with different identifiers, dates, amounts and product classifications.

I find that gap more interesting than another promise about borderless commerce. Physical borders, inspections and legal duties are real. They cannot be removed by software. But much of the administrative friction comes from the need to reconcile information that has already been entered somewhere else. The United Nations Centre for Trade Facilitation and Electronic Business has spent years developing data models and standards precisely because shared meaning across organizations is a difficult engineering and governance problem. 1

Scope and disclosure.

This is an independent engineering analysis, not a claim that every example happened in one particular deployment. Scenarios are illustrative; technical examples are sanitized and omit clients, products, credentials, and private integrations. Factual claims are linked to public sources. Photography is credited to the original Unsplash photographer.

One shipment can have several competing identities

The seller knows a purchase order number. The bank knows a payment reference. The freight company knows a consignment number. The carrier may identify containers, and customs may assign declaration identifiers. None is necessarily wrong. The problem begins when an operator has to determine whether they all refer to the same commercial obligation without a reliable chain of references.

It is tempting to introduce one universal transaction identifier, but not every participant is under the same authority. A more realistic design uses stable identifiers within each domain and well-defined relationships among them. A correction, split shipment or partial payment should preserve those relationships rather than overwrite a single number. The system needs to represent what actually happened, even when it differs from the original purchase order.

The same product can mean different things

An invoice line may contain a merchant's product name, manufacturer part number, packaging unit and tax treatment. A customs declaration needs tariff classification and country of origin. A warehouse needs the exact item and quantity received. Data exchange succeeds only if the participants can reconcile those meanings, and sometimes the rules differ legitimately by jurisdiction.

This is why message formats alone do not create interoperability. Two systems can exchange valid JSON and still disagree over whether a quantity means individual units, boxes or kilograms. Standards such as UN/CEFACT reference data models and World Customs Organization classifications provide a common language, but implementation must also resolve local definitions, units, currencies and exceptions. 12 Where uncertainty cannot be eliminated safely, it should be made reviewable rather than hidden behind automatic matching.

Digital paperwork can reproduce the same manual work

A company may proudly replace paper forms with PDFs. Another institution receives the PDF and retypes its contents into a different portal. The process is now electronic, but the underlying information is still being transferred by human transcription. Machine-readable, signed documents can reduce that duplication only when the receiving party recognizes the schema and the trust framework behind them.

A proper transaction exchange should allow structured fields, validation results, document provenance and lifecycle events to travel together. Changes must be represented explicitly. An invoice amended after shipment should not silently alter what the customs officer originally reviewed. The WTO Trade Facilitation Agreement recognizes the importance of modernizing and simplifying procedures, but the operational value depends on how institutions implement them. 3

Payment and shipment status are different truths

A buyer may pay a deposit, a seller may prepare goods, and a freight company may accept the cargo while customs clearance remains pending. There is no single 'complete' flag that faithfully captures all of those states. Treating commercial, financial and logistics finality as one status can produce mistaken releases or payment expectations.

A better system has explicit domain lifecycles and rules connecting them. A trade-finance workflow can verify that required evidence exists before authorizing a disbursement. A warehouse can show whether an item was physically received even if an invoice is still disputed. The identifiers should make the relationships traceable without forcing every domain into the same database. This is a useful role for event-driven integration when events have well-defined semantics and replay behavior.

Trust must cross legal as well as technical boundaries

An electronic signature that is accepted in one jurisdiction may not automatically satisfy another's evidentiary requirements. A document can be authentic but issued by an institution the receiving party does not recognize. Data may be legally restricted from crossing a border. The receiving system needs to distinguish transport security from the legal meaning of the underlying claim.

There is no purely technical solution to these questions. Agreements over recognition, liability, dispute resolution and privacy have to exist alongside APIs. The OECD's work on digital trade emphasizes that enabling trade requires coherent rules and institutional coordination, not only increased digital adoption. 4 A good technical system makes the rules explicit and testable rather than pretending every jurisdiction is interchangeable.

Trade systems need to tolerate imperfect partners

International transactions involve parties using different software, infrastructure and operational schedules. Messages arrive late. Some participants send duplicate events. A shipment can be partially delivered. A provider may update an earlier record or introduce a new schema version. An architecture that assumes synchronized, perfect partners will spend its operational life handling exceptions manually.

Stable message identities, versioned contracts, validation at boundaries and durable reconciliation queues make the differences manageable. Some checks should be synchronous because they determine whether a transaction may proceed; others can be asynchronous because evidence arrives over time. The distinction should be documented. A failed API response must not erase a verified customs clearance or paid invoice. Correction should preserve history, making it possible for each participant to understand which version of an assertion it accepted.

Start with one complete trade corridor

A global interoperability vision can become too abstract to implement. I would begin with a narrow corridor and a defined transaction type. Map the data fields, authorities, financial events, transport milestones, and documents exchanged. Agree on identifiers and precise status meanings. Then test partial deliveries, corrections, disputed classifications and unavailable participants before attempting broad deployment.

The business measure is not the number of organizations connected to an API gateway. It is the reduction in duplicate entry, document errors, customs delays and unresolved exceptions for real shipments. Once an end-to-end transaction works reliably, the same architecture can be extended to more participants. The UNECE and WCO standards provide tools; the operational proof still has to come from a working process. 12

What follows

Digital trade infrastructure will not remove every barrier to international commerce, and it should not attempt to bypass legitimate legal controls. But it can reduce the avoidable work created when organizations repeatedly reinterpret the same transaction.

The opportunity is to create a reliable chain of evidence across invoices, payment instructions, shipments and official declarations. When those records can agree about what they know and expose where they disagree, cross-border commerce becomes easier to operate and easier to trust.

Sources and further reading

  1. UNECE: UN/CEFACT standards
  2. World Customs Organization: Data Model
  3. WTO: Trade Facilitation Agreement
  4. OECD: Digital trade
  5. UNECE: Trade Facilitation Recommendations
  6. UN: Digital trade and electronic commerce