ERP integration in importing is not about buying a connector: it is about making data enter once. Why bridge spreadsheets end up on IT's desk and how to avoid it.
For many IT teams at importing companies, the fear is not the new ERP. It is everything hanging off it: the bridge spreadsheet someone updates every morning, the manual uploads from the TMS and the customs data that gets typed in all over again. That is why, when it comes to ERP integration in importing, the real question is not which connector to buy, but how to make every piece of data enter once and reach the right place without opening yet another maintenance front.
This article explains what ERP integration means for a company that imports, why improvised integrations always end up on IT's desk, and which criteria to use to bring order to data flows, especially when an ERP change is under way.
ERP integration is connecting the ERP with the company's other systems so they share data automatically: orders, invoices, suppliers, stock or costs. General explanations usually use the CRM or the online store as examples. In an importing company the map is more complicated, because much of the data the ERP needs does not originate inside the company.
It arrives in third-party documents: the supplier's commercial invoice, the shipping line's BL, the forwarder's arrival notice, the freight invoice with its surcharges or the customs declaration returned by the customs broker. Each has its own format and timing, and almost none of them fits the ERP's data model directly. Integrating the ERP in importing therefore means solving two problems at once: connecting systems to each other (ERP, TMS, CRM, customs system) and turning external documents into structured data those systems can use.
When that second problem goes unsolved, the business solves it on its own, with whatever is at hand. That is how integrations appear that are on no architecture diagram but hold up day-to-day operations. The three most common at importers are:
None of these is a mistake by whoever set it up. They are a reasonable response to a real need the system did not cover. The problem is what happens next, when the temporary fix has been in production for three years.
An improvised integration has no clear owner, but it does have a de facto one when it breaks: the IT team. And it breaks more often than it seems, because it rests on fragile assumptions. A column that moves in the TMS export, a macro that stops working after an Office update, or the one person who knew how the sheet worked going on holiday.
These integrations also leave no trail. If an import cost is wrongly allocated in the ERP, it is very hard to tell whether the error came from the original document, the transcription or a formula. Without traceability, every incident becomes a manual investigation, and every investigation takes IT hours nobody had planned for.
The result is a familiar pattern: the IT team spends more and more time maintaining connections it never designed, and every new business need (a new supplier, a new route, a new forwarder) adds another patch to the pile.
ERP replacement projects tend to focus on the ERP itself: master data migration, configuration, training. Whatever hangs off it is left for the end, and that is where the risk lies. If the new ERP is connected by replicating the same manual uploads and the same bridge spreadsheet, the company will have changed systems without changing the problem, and will have to rebuild fragile integrations on a platform it does not yet know well.
That is why an ERP change is the best moment to take stock of data flows. Three questions are enough for each piece of data entering the ERP: where does it come from, who transforms it, and how many times is it typed in? If the answer to the last one is “more than once”, there is an integration waiting to be designed.
There is no single right method: each one fits a type of flow and carries a different maintenance cost. The most common in an importing company's environment are these:
For an IT team, the deciding factor is rarely the technology itself, but how many pieces it will have to maintain and who will answer when data arrives wrong. Fewer loose pieces and more traceability mean fewer open fronts.
Take a components importer that receives several containers a month from Asia. Before its flows are put in order, each import works like this: the order lives in the ERP; the commercial invoice arrives by email and someone in Purchasing matches it against the order in a spreadsheet; the forwarder sends the arrival notice and the freight invoice, which Logistics enters by hand into the TMS; and when the customs broker returns the customs declaration, Accounts types the customs value, duties and import VAT into the ERP to work out the real landed cost. The same shipment goes through three people and four transcriptions, and the unit cost is not available until weeks later.
With a connected data layer, documents are read as they arrive, the data is validated against the order and the rates, and it is loaded into the ERP and the TMS with no re-keying. People only review the exceptions: an invoice that does not match the order, or a surcharge that was not in the rate. IT stops maintaining the bridge sheet and the weekly uploads, and gains something it never had before: a record of which data came from which document, and when.
10+ native integrations with ERPs, TMSs and CRMs, and implementation in 8-10 weeks.
In importing, data quality is not only about efficiency. The Union Customs Code (Regulation (EU) No 952/2013) sets out in Article 6 that information exchanged between traders and customs authorities must be handled electronically. And whoever lodges a declaration is responsible for the data being accurate and complete.
For a company acting as importer of record, this means that a transcription error between the commercial invoice, the customs system and the ERP is not an internal issue: it can end up in an incorrect declaration. Integrating well is not only about saving hours, but about being able to show where every piece of data comes from. To go deeper into that document, see our guide to the customs declaration (DUA).
Before approving a new integration, whether during an ERP change or to cover a one-off need, IT should be able to answer five questions:
If several answers are unclear, the integration will probably end up as another bridge spreadsheet with a nicer look.
Good ERP integration goes unnoticed: data arrives, it reconciles and it can be traced. Achieving that in importing does not require replacing the ERP or building a new architecture, but removing the points where data is typed in more than once. It is the same idea behind logistics digitalization and invoice automation: start with the flow that has the most volume and the most errors, measure and expand.
K-Plug starts from that principle: it does not replace your ERP, it feeds it with clean, traceable data. It connects natively with your ERP, TMS or CRM so every piece of data enters once and reaches the right place.
It is connecting the ERP with the company's other systems (TMS, CRM, customs system) so they share data automatically. For importers it also means turning third-party documents such as commercial invoices, BLs or customs declarations into structured data the ERP can use.
No. A data layer can connect natively to your current ERP and TMS and feed them with clean, validated data, without migrations. Replacing the ERP is a separate decision and does not remove re-keying on its own.
It depends on the flow. File exchange and point-to-point APIs work for simple connections, but logistics data comes from documents, so the most robust option combines document data extraction with native ERP, TMS and CRM connections and keeps a record of each data source.
They have no clear owner, break with any format change and leave no trail, so every error becomes a manual investigation. Over time IT spends more hours maintaining connections it never designed.
No, Kaiona is not a traditional SaaS. We don't sell you a generic platform that you have to adapt to, nor a monthly user license for your team to do the work.
Kaiona functions as a custom artificial intelligence and automation layer that connects directly with your current systems (ERPs, CRMs, document management). We handle the technical complexity so that you only see the results within your usual workflow.
.png)
.png)
