System Integrators · Multi-Vendor BOM · Project-Level IOR

Importer of Record for System Integrators

System integrators are paid to make complicated technology projects look simple. The solution is signed off, the hardware is sourced from five vendors, the installation dates are fixed, and then someone asks who is going to be named as importer in the destination country. TFTIOR provides the Importer of Record structure for international IT, network, data center and telecom deployments where the integrator has no local entity and the customer cannot or will not take the role. The equipment is reviewed at BOM level before dispatch, not at the border.

Veyis Taskin Founder & CEO, TFTIOR · LinkedIn · Updated September 2026

Send Your BOM for Import Feasibility Review View Documented Case Studies

The Import Gap in International System Integration Projects

System integration projects are designed around technology, commercial scope and deployment dates. Customs tends to arrive in the conversation late, usually once the hardware is already bought. That creates a predictable gap. The integrator has assembled and sold the solution, the customer expects delivery to site, the equipment is sitting in a warehouse, and neither party is actually positioned to become the legal importer in the destination country.

The pattern repeats across markets. The integrator has no local entity. The customer holds no import registrations, or holds them but will not use them. Procurement wants DDP. The end user is not the buyer of every component in the rack. Local rules require a licence, a type approval or a product registration that nobody priced into the project. The same hardware is going to four countries under one commercial agreement, and only one of those countries is straightforward.

None of this is a transportation problem. It is import responsibility. An Importer of Record is the local legal entity that takes the importer role and carries the customs and regulatory obligations that come with entry. For an integrator it is often the difference between winning an international project and telling the customer that delivery stops at the border. We set out the wider comparison in Importer of Record vs setting up a local entity and in the non-resident Importer of Record model.

One Import Structure for a Multi-Vendor Project

An integrator rarely deploys one product. A single infrastructure project can carry equipment from five, ten or twenty manufacturers: servers, storage, switches, routers, firewalls, GPU and AI compute nodes, wireless equipment, PDUs and UPS units, optical transceivers, cabling, racks, security appliances, power supplies, spares and installation accessories.

From the customer's side this is one solution. Customs does not read it that way. Every product can carry a different tariff classification, regulatory status, origin treatment and documentation requirement. A server may be simple. A wireless access point may need local telecom approval. A security appliance may contain encryption functionality. A refurbished device may fall under a completely separate import regime. A PDU may need conformity paperwork that has nothing to do with the switches travelling in the same crate.

This is the case for reviewing integrator projects at BOM level rather than at shipment level. The point is to understand the import path before the goods start moving, which is the same discipline we apply on server and data center equipment and on GPU and AI hardware.

Pre-Shipment BOM and Compliance Review

One of the most expensive mistakes in international technology deployment is finding a compliance problem after the shipment has landed. By then storage is accruing, the installation team is booked, the customer is asking for a date and the remaining options are much narrower than they were a fortnight earlier.

For system integration projects TFTIOR reviews the planned equipment before dispatch. Depending on the market and the hardware, that review covers product descriptions, manufacturer and model numbers, HS classification, country of origin, declared customs value, new or refurbished status, wireless functionality, encryption functionality, technical conformity requirements, telecom or radio approvals, product registration requirements, import licensing, dual-use considerations, end user information, shipping origin, Incoterms, final delivery destination and the project timing the deployment actually needs.

This is not paperwork for its own sake. It is finding the problems while they can still be solved. A missing certificate discovered before dispatch may cost two days at the origin. The same certificate discovered after arrival can move a deployment date by a month. Where certification is involved, the certification lead time matrix gives an indication of how much runway a given approval usually needs, and the full process sits under pre-shipment compliance review.

From BOM to Deployment

A well-structured IOR project normally starts before the freight booking. The sequence below is what an integrator project looks like when the import side is set up properly rather than retrofitted.

1. Project scope

   Destination country, equipment list, commercial value, shipping origin and intended delivery location. For larger projects a full BOM is far more useful than a summary description, because the summary is exactly where the problem items hide.

2. Import feasibility review

   The equipment is assessed against local customs and regulatory requirements. Restrictions, approvals, licensing requirements and documentation gaps are identified while the project can still absorb them.

3. Importer confirmation

   The legal importing structure is confirmed before shipment. The Importer of Record should not be an afterthought bolted on once the goods are already in transit, which is the point we make in when an IOR is needed before shipment.

4. Shipping instructions

   Commercial and shipping documents are aligned with the agreed importer structure: invoice wording, importer details, consignee details, product descriptions and whatever else the destination market specifically requires.

5. Regulatory preparation

   Where required, certifications, permits and product approvals are handled before or during the import process rather than discovered at the port.

6. Customs clearance

   The shipment enters the destination market under the agreed Importer of Record structure, with the declaration supported by the file built during the review.

7. Delivery

   Once released, the equipment moves to the end user's office, data center, warehouse, integration facility or other deployment site, including multi-site distribution where that was planned in advance.

8. Import evidence and project records

   Customs documentation, proof of delivery and other records are retained for the project file. On enterprise deployments this set is usually requested later by procurement, finance, compliance or internal audit, and it is much harder to assemble after the fact. Clients using the TFTIOR Client Portal keep the shipment-linked record rather than an email thread.

DDP Delivery Without a Local Entity

Most integrators meet the same commercial request: can you deliver the equipment to our site and handle everything. From the customer's side that is a reasonable thing to ask. They bought a technology solution, not a customs project. So the integrator is expected to quote DDP or delivered-to-site.

DDP raises a question that a quote template does not answer. Who is actually going to be the importer? The integrator may have no entity in the destination country. The end customer may refuse the role outright. The freight forwarder can arrange clearance, but arranging clearance and being the importer are not the same thing, which is the distinction we set out in freight forwarder vs Importer of Record.

An IOR structure closes that gap by separating the commercial sale from the local import responsibility. The integrator keeps the customer relationship and the contract. The local importing entity carries the customs and compliance layer. That separation is what makes a DDP quote deliverable in a market where you have no presence at all.

Protecting the Integrator's Customer Relationship

There is a second, less technical reason integrators use Importer of Record services, and in some deals it matters more than the customs one.

The alternative is often to bring a local reseller into the transaction. That can solve the import problem and create a commercial one. The integrator has spent months developing the customer, designing the solution and winning the project. Handing the import and resale portion to another technology reseller puts a competitor directly inside that account, with visibility of the pricing, the scope and the customer contacts.

An independent IOR works differently. The IOR exists to perform the import function. It does not need to become the customer's technology supplier, and it has no reason to be in the account next year. The integrator stays the integrator, the OEM stays the OEM, the end user stays the end user, and the Importer of Record carries the legal import responsibility required to bring the goods into the market. For a lot of VARs and integrators, that boundary is the whole point.

Multi-Country Rollouts

Integrators increasingly work on regional or global deployments. A customer wants the same infrastructure in ten countries. The hardware architecture is identical in all ten. The import requirements are not identical in any two.

A product that clears easily in one jurisdiction may need registration in the next. Wireless equipment may need additional approval. Used hardware may be permitted in one market and restricted across the border. Customs valuation rules differ. The entity that can legally act as importer can also change by market. Treating each country as an unrelated shipment is how rollouts lose two months in the middle.

A centralised IOR model handles this differently. The project stays one commercial engagement with one point of coordination, and the import structure adapts market by market underneath it. That model suits network refresh programmes, branch infrastructure rollouts, SD-WAN deployments, cloud infrastructure projects, cybersecurity appliance deployments, server refresh work, AI and GPU infrastructure, retail technology deployments and multinational office upgrades. Regional detail sits on our LATAM, EMEA, Southeast Asia and Central Asia pages.

Split Shipments, Multiple Origins and Phased Deployments

Real projects are rarely as clean as one factory shipping to one customer. A deployment may pull servers from Taiwan, network equipment from the Netherlands, firewalls from the United States, PDUs from Germany and spares from Singapore, with racks sourced locally and separate deliveries coming from three distributors. Some items ship immediately. Others have a six-week lead time. The customer still sees one project.

Import planning therefore has to support split shipments, multiple origin countries, partial deliveries, phased deployment, different equipment vendors, different commercial invoices and project-specific delivery windows. Not every project needs to arrive on one airway bill, and forcing it to is usually more expensive than planning around it.

Large infrastructure projects are often delivered in phases: core networking first, compute second, expansion hardware or additional sites third. Across those phases, customs clearance cannot be treated as an isolated transaction each time something lands. The equipment list, classification logic, regulatory status and importer documentation should stay consistent across the rollout, otherwise phase three arrives declared under a description that contradicts phase one. Consistency reduces the risk of conflicting declarations and leaves a cleaner audit trail behind the project.

Delivery to Data Centers, Offices and Customer Sites

Customs clearance is one part of the project. After release, the equipment still has to reach the right place, and on integrator projects the right place is often several places.

Delivery may run to enterprise offices, data centers, branch locations, warehouses, integration facilities, telecom sites, customer campuses or multiple end user locations across a country. Some projects need one final delivery. Others need distribution to twenty branches after clearance, sequenced to match the installation schedule. That requirement should be known during the initial project review. Adding it after the goods have cleared usually means the equipment sits somewhere while the plan is rebuilt.

IT Equipment Is Not One Regulatory Category

The phrase "IT equipment" covers an enormous range of products, and import regulation does not treat them equally. A single integrator BOM usually spans several of the groups below, which is exactly why the pre-shipment review matters.

Regional Requirements Shape the Rollout

The same BOM meets a different regulator in every market, and a rollout plan that ignores this tends to fail in the third country rather than the first. In Turkey, telecom and radio equipment sits under BTK oversight, with conformity procedures running through TAREKS and device identity registration through MCKS. Saudi Arabia handles conformity through SABER and SASO, with telecom under CST. Malaysia routes equipment through SIRIM and MCMC. Brazil assesses network and telecom hardware against ANATEL and INMETRO. Mexico applies telecom requirements through the CRT. Egypt works through NTRA, the Philippines through NTC permits for radio-enabled devices, and Uzbekistan through UzRCI.

Requirements for radio functionality, conformity documentation and used or refurbished equipment differ materially between these markets, and they change more often than a project schedule allows for. Rather than restate them here, the current position for each market sits on the country pages, including Turkey, Saudi Arabia, UAE, Malaysia, Brazil, Mexico, Singapore, Philippines, Vietnam and India. For a rollout, the practical takeaway is simpler: the hardware repeats across countries and the approval path does not, so each market needs its own answer before the phase is scheduled.

When the End Customer Should Not Be the Importer

It is tempting to assume the end customer can simply act as importer. Sometimes they can. Often they should not, and occasionally they legally cannot.

A customer may decline the role because it does not normally import equipment, because it lacks the required registrations, because internal procurement policy prohibits it, because its legal entity is not permitted to import that equipment, because finance does not want unexpected customs liabilities on its books, because compliance does not want importer responsibility, because the hardware is being supplied under a service contract rather than sold, because the commercial agreement requires delivered-to-site execution, or because the local presence is a branch office rather than an importing entity.

Using the end user's name on a declaration without confirming that it can legally and operationally fulfil the importer role is not a solution. It is a deferred problem with the customer's name on it. The importer should be identified before dispatch, and the full exposure is set out in our Importer of Record liability explainer.

Importer of Record, Freight Forwarder, Customs Broker, Distributor

These four roles get used interchangeably in project conversations. They are not interchangeable, and the difference only becomes visible when a declaration is questioned.

For integrator projects the framing matters. The question is not who can clear the shipment. The better question is which legal entity can be named as importer for this project, and whether that entity can defend the declaration afterwards. Where the name on the declaration is rented and has no ability to stand behind the file, the problem is the one we describe as a paper IOR. The broker comparison sits in Importer of Record vs customs broker, and the coverage question in real IOR coverage vs logistics coverage.

Importer Liability Is Not an Administrative Title

Being named as Importer of Record is not a formality on a document. The importer can carry responsibility for customs declaration accuracy, tariff classification, customs valuation, origin information, import taxes and duties, product compliance, document retention, regulatory declarations and any post-entry customs review that follows months later.

That is why the importer should be identified and documented before shipment. On enterprise projects, procurement should be able to answer one question without checking: which legal entity is being named as the importer on the customs declaration. If nobody can answer that before dispatch, the shipment structure is not finished, whatever the freight quote says. Valuation exposure in particular is covered in customs valuation risks on technology imports.

System Integrator Deployment Scenarios

The projects below cover most of what reaches us from integrators, VARs and infrastructure providers. The equipment differs. The structural question rarely does.

Refurbished Equipment Inside an Integrator BOM

Used and refurbished technology needs its own answer. Many countries apply different rules to second-hand equipment, and the rules are rarely written where a project manager would look for them.

Depending on the destination, requirements can include prior import permission, age limitations, technical inspection, additional documentation, environmental controls or product-specific approvals. Some markets restrict used equipment almost entirely. Others permit it under defined conditions. For integrators working on hardware refresh, lab environments, spare pools or cost-sensitive infrastructure, this should be checked before purchase. Buying the equipment first and asking whether it can be imported afterwards is one of the more expensive ways to learn a market.

TFTIOR holds the regulatory qualifications and after-sales infrastructure required to act as the real importer for eligible refurbished enterprise IT equipment in Turkey, and assesses comparable routes in other legally supported jurisdictions. Capability in one market is not evidence of the same capability everywhere, so each destination is reviewed separately.

Reverse Logistics and RMA After Deployment

The import is not the end of the equipment lifecycle. Hardware fails, projects change, assets are refreshed and equipment moves between countries. All of that creates further customs movements after the deployment is signed off.

A replacement unit needs to enter the country. A failed device needs to leave. An old server goes back to the vendor. Equipment is transferred to another data center. This is where Importer of Record, Exporter of Record and reverse logistics start to overlap, and using a provider that holds the whole lifecycle simplifies warranty replacement, RMA movements, temporary replacement equipment, defective hardware export, equipment return, redeployment, asset relocation and decommissioning projects.

The original deployment and the eventual reverse movement should not be handled as unrelated processes by unrelated providers. The detail sits on our reverse logistics and RMA page.

Project-Based IOR Instead of Shipment-Based IOR

The most useful way to support an integrator is to understand the project rather than the freight. The difference shows up in the first email.

A shipment-based question sounds like: can you clear these six pallets. A project-based question sounds like: we are deploying a multi-vendor infrastructure stack into three countries over the next four months, what needs to happen before the first shipment. The second question produces a much better import plan, because classification, compliance, importer structure and delivery requirements can all be settled before the schedule turns critical.

For larger deployments it also changes the commercial picture. An integrator that knows the import cost and regulatory risk before quoting can price the international project properly instead of absorbing surprises later. That is the same argument we make on IOR as market entry infrastructure and in why global IOR providers fail on IT hardware imports.

What Drives the Cost

There is no list price for project IOR, because integrator projects are not uniform. The cost tracks the depth of review the deployment actually needs.

The factors that move it are the number of distinct line items in the BOM and how many regulatory categories they span, the declared value and duty exposure, the product risk tier (a passive patch panel is not a GPU node), the number of destination countries and origin countries involved, whether any item is refurbished or used, whether radio, encryption or dual-use functionality is present, the number of separate consignments and phases, whether multi-site distribution is required after clearance, and how much runway exists before the installation date. A single-country shipment of standard enterprise servers sits at one end. A four-country phased rollout with wireless approvals, mixed new and refurbished assets and controlled hardware sits at the other. For a first indication, the IOR compliance calculator and shipment estimator give a starting point, and the scope is stated before anything moves.

What We Need to Review a Project

An initial feasibility review does not need to be complicated. The information that usually settles it is the destination country, the equipment list or BOM, manufacturer and model, quantity, commercial value, country of origin, shipping origin, new or refurbished status, end user information, final delivery location, intended Incoterm, required delivery date, any wireless or cellular functionality and any known encryption functionality.

Why System Integrators Use TFTIOR

International infrastructure projects need more than freight forwarding. They need someone who understands where logistics, customs, product compliance and deployment timing intersect, and who will say what cannot be done before the cargo moves rather than afterwards.

TFTIOR focuses on Importer of Record and Exporter of Record services for technology equipment and complex cross-border projects, including servers, networking hardware, telecom equipment, data center infrastructure, storage systems, AI and GPU hardware, security appliances, refurbished IT equipment and other regulated technology products. We support individual shipments as well as phased and multi-country deployments, and the importer structure is established before dispatch so the project team knows who carries the import responsibility before the freight moves. Where an integrator is building cloud or AI capacity for a customer, that work sits alongside our cloud and AI infrastructure IOR and end-to-end data center deployment practice.

Export controlled hardware is screened before release, covered under US export controls (EAR and BIS) and dual-use compliance. Where a project cannot be structured compliantly, we say so instead of taking the booking, which is also why shipments that reach us already stuck are handled separately under stuck shipments.

Build the Import Plan Before the Shipment

No integrator should have to redesign a project because the import structure was considered too late. Before the hardware ships, the project team should know who the importer will be, whether the equipment can legally be imported, what approvals are required, what documents need to travel with the shipment, how customs value will be declared, how the equipment reaches the final site, and what happens when something later needs to be returned or replaced.

Once those seven questions are answered, international delivery stops being the risky part of the project. If you are planning a deployment into a country where neither your company nor your customer can act as importer, send the destination and the equipment list. We will review the proposed structure before dispatch.

Frequently Asked Questions

Can a system integrator use an Importer of Record if the customer is the final consignee?

In many markets yes, subject to the rules of the destination country. The Importer of Record and the final consignee do not always have to be the same entity, but the structure has to be confirmed before shipment rather than assumed, because a minority of jurisdictions do require the importer to be the receiving party.

Can one Importer of Record handle equipment from multiple manufacturers?

Usually yes. A multi-vendor deployment can generally run under one coordinated importer structure, but each product still needs its own classification, origin and regulatory review. The single importer simplifies the commercial and customs structure, not the product compliance work behind it.

Can you support shipments from multiple origin countries?

Yes. System integrator projects frequently pull hardware from several origins at once, for example servers from Taiwan, network equipment from the Netherlands and firewalls from the United States. Each shipment is reviewed inside the same project structure so the declarations stay consistent across origins.

Can an Importer of Record be used for DDP projects?

Where the destination permits it and the structure is set up correctly, yes. This is one of the most common reasons integrators use an IOR: the customer has asked for delivery to site and the integrator has no importing entity in that country. The IOR carries the import responsibility while the integrator keeps the commercial contract.

Does the end customer need to act as importer?

Not necessarily, and in several situations they should not. Whether the customer can act as importer depends on local regulation, the customer's registrations and legal status, and the commercial structure of the project. A branch office, a service-contract recipient or a company with no import registrations may be unable to take the role even if it is willing to.

Can servers, switches and other equipment be imported together?

Often yes, but each product category carries its own classification and compliance requirements. A server, a wireless access point, a firewall with encryption functionality and a PDU can sit in the same crate and still face four different regulatory paths. The complete BOM should be reviewed before dispatch.

Can you support phased deployments?

Yes. Phased rollouts are normal in system integration work, and they are better handled under one project-level import structure. Keeping the classification logic, product descriptions and importer details consistent across phases avoids the situation where phase three is declared differently from phase one.

What happens if one product in the BOM requires certification?

That item may need separate documentation, an approval process or different timing from the rest of the shipment. Finding it before dispatch usually means splitting one line item out of the consignment. Finding it after arrival can mean the whole shipment waits for one access point.

Can you handle replacement equipment and RMA shipments after deployment?

Yes. Warranty replacements, defective unit returns, advance replacement and asset relocation can be structured using Importer of Record and Exporter of Record services where appropriate. The return path is easier to build when the original import file was created with that possibility in mind.

Can our company remain the seller to the end customer?

In most IOR structures, yes. The Importer of Record performs the import function without becoming the customer's technology supplier. That is the practical difference between using an IOR and routing the project through a local reseller, which introduces another technology seller into an account you developed.

Can you deliver to multiple sites after import?

Depending on the country and the project, yes. Distribution to several branch or data center locations after clearance can be planned as part of the deployment, but it should be raised during the initial review rather than after the goods have already cleared customs.

When should a system integrator involve the Importer of Record?

Ideally before the purchase order is finalised, and certainly before shipment. Early involvement leaves time to identify restrictions, certification lead times and documentation requirements while they can still be solved. It also lets the integrator quote the international project with a realistic view of import cost and regulatory risk.

Related Resources